exceptions move

[wojtek0806]

As we currently have a ton of exceptions defined across different points in the SDK, I would want to move those into a single place: sdk_exception.py and from now on any exception should be defined there. This will make things easier to follow in my opinion.

I would also like to remove one of the exceptions as they basically do the same thing:

• UnsupportedOperation
• UnsupportedMethod

Unless we clearly define them and use them as per the definition, one of the should go. I vote for UnsupportedMethod to be removed.

If I do not hear anything against this I will proceed with PR :)

[wojtek0806]

@caphrim007 @zancas @pjbreaux @swormke @jasonrahm @jlongstaf

[caphrim007]

@wojtek0806 I'm supportive of this reasoning to the extent that the exception class applies to more than just one use case.

[wojtek0806]

I have moved the exceptions, now there is an open question of either removing one of this:

• UnsupportedOperation
  

• UnsupportedMethod
  

Or making clear distinctions between them and correcting where needed, which will break compat, also there is one Exception in snat.py called:

RequiredoneOf , which serves the same purpose as the one found in sdk_exceptions.py. I would like to change it but again this will break compat as the exception message will be different.

@caphrim007 @zancas @pjbreaux

[caphrim007]

the RequiredOneOf in sdk_exceptions was made specifically to handle the cases in the iworkflow/bigiq modules. The names are not the same, although they are close.

You can make the snat one work with the sdk_exception one by just making the code be a list of lists; adding [ ] around the existing list.

[wojtek0806]

Adding further thought on how to split those 2 exceptions, I think defining those exceptions clearly in the docs is the this is the best way to do so, rather than removing one of them completely.

• UnsupportedOperation: This exception will only be raised when an endpoint does not support the underlying HTTP method, that means: HEAD, POST, GET, PUT, PATCH, DELETE. This would mean that if for example we send POST but it requires some specifics, for example empty json {}, as in the case of ASM Tasks. We would NOT use this exception when coding.

• UnsupportedMethod: This exception will only be raised if a given method is not supported for specific endpoint, for one reason or the other. This exception MUST NOT imply that the underlying HTTP operation is completely unsupported, only THAT the class method will not work.

@caphrim007 @zancas @pjbreaux @jasonrahm

Refactoring the code to adhere to the above will result in some of the exceptions changing, so will break backward compatibility.

We have to do this sooner than later in order to have this SDK remain consistent.

[wojtek0806]

closing due to lack of interest

[caphrim007]

not a lack of interest, only a lack of time to address it