Option to raise exception on error codes #254
Replies: 2 comments 12 replies
-
I actually had the generated functions raising exceptions previously when there was an unexpected status code, but I took that out because of the lack of static checking for exceptions. As far as I've seen, there's no handy tool to tell you "hey this function could throw an exception but you aren't handling it" whereas having something be I hesitate to add a bunch more functions for exactly the reason you point out - code bloat - but you're right that having to call Is this the sort of thing that you would always want for a given client? Maybe it would be better to have this as a generator option? If set it could call |
Beta Was this translation helpful? Give feedback.
-
FYI I've seen enough interest in this that it's definitely something I'd like to implement as an option eventually. I've created issue #491 and added it to the long term 1.0 project. I don't anticipate this landing very soon, but it will happen 😁 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Is your feature request related to a problem? Please describe.
In some cases, if an unexpected error code is returned (or even an expected error code), I would rather raise an exception than return
None
. This is because depending on the linter and adoption of type annotation in a code base I may not handle aNone
variable. In this case an exception raising status code, message or other meta data would be more useful to debug especially when using exception logging software like Sentry.Describe the solution you'd like
I see a couple of interface possibilities if this feature would make sense to implement.
Add new functions with a must prefix:
must_sync
must_sync_detailed
must_async
must_async_detailed
This is inspired by a Golang's pattern of prefixing "must" to functions which may panic. The main downside is the addition of 4 new methods.
Another solution would be to provide a
raise_for_status
method similar to python requests library on theResponse
object. This interface would allow the passing of args to specify raising in case of any error code or just unexpected ones. The side effect here is that like remembering to handle None you would have to remember toraise_for_status
. This side effect exists when using the requests library so is not a big deal.Describe alternatives you've considered
Currently in cases where I would like to fail hard, I have a wrapper function which takes a
..._detailed
function and builds an exception with meta data ifparsed
isNone
. This works fine.Interested in thoughts/discussion!
Beta Was this translation helpful? Give feedback.
All reactions