-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Macaroon.deserialize raises very general exceptions #50
Comments
|
As well as a generic
The latter is probably a bug, IMO this library should never produce a generic |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Macaroon.deserialize
can raise at least:MacaroonInitException
(if the input is None or empty)ValueError
(various causes depending on the serializer: if the input is a non-UTF-8 byte string or invalid JSON, or if a packet header isn't valid hex)TypeError
(if base64 padding is wrong, although admittedly this can only happen if there's a programming error in the padding-restoration functions)struct.error
(if encountering a short packet)MacaroonDeserializationException
(various causes)This puts calling code in the position of having to catch a lot of exceptions, and given that the range of possibilities is not documented it often ends up being best to catch
Exception
, but that means that it's very easy to accidentally mask programming errors, which is unsatisfactory.Ideally it should be guaranteed that
Macaroon.deserialize
only ever raisesMacaroonDeserializationException
, or at least some subclass ofMacaroonException
, so that calling code can catch anything raised by pymacaroons while being confident that it won't accidentally catch exceptions raised by other code. And, in any event, the possible exceptions should be documented.The text was updated successfully, but these errors were encountered: