api: Make a structured exception type for API errors, and use it #37
Labels
a-api
Implementing specific parts of the Zulip server API
Comments
|
Some API errors are for conditions that we'll want to recognize as fatal to the current API connection: the user's auth credential was invalidated, the realm or user was deactivated (see zulip/zulip-mobile#4571), possibly more. (Maybe the invalid-event-queue error?) When working on this issue, I wonder if we need to think about those API errors differently than more mundane ones, like when you tried to send a message with a too-long topic. |
This was referenced May 23, 2023
gnprice
added a commit
to gnprice/zulip-flutter
that referenced
this issue
May 24, 2023
These are quite a lot like the ones we have in zulip-mobile, defined in `src/api/apiErrors.js` there. The main differences are: * Each exception has a `routeName` property, to identify what route was involved. This is information that can be quite helpful in debugging; and while it should typically be possible to work it out from looking at the stack, it's nicer to be explicit. * The exception types are named like FooException, whereas they're FooError in zulip-mobile. This is just to conform to Dart convention, where there's an Exception type and an Error type, and these are definitely Exception and not Error because they don't necessarily represent any bug in the program. Fixes: zulip#37
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Like the
ApiErrorand its base classRequestErrorthat we have in the RN app insrc/api/apiErrors.js.The text was updated successfully, but these errors were encountered: