Exception handling in the API¶
Exceptions over websockets¶
In response to an RPC call, instead of returning a response, you might get
an exception. For this purpose we use the WAMP message type
which looks as follows:
[4, callID, "http://domain/exceptions#ExceptionType", message] [4, callID, "http://domain/exceptions#ExceptionType", message, details]
It might also happen that an error condition happens which is not handled on the server at all, in which case the returned exception frame looks like this:
[4, "ce6th2qed7j", "An error occurred."]
Exceptions over HTTP¶
When using HTTP to call RPC methods, in case of a known exception, the status code in the HTTP response is 400, and the response payload is a JSON object with the following attributes:
If a completely unexpected error happens, the HTTP response is just a 400
Bad Request as the payload.
UserException(name, message, data=None)¶
RPC exceptions consisting of the machine-readable CamelCase exception name, a human-readable error message, and an optional object with any additional details depending on the type of exception.
Exceptions should follow the following rules:
- messages are user friendly
- messages are translated on the server side
- exceptions not do not expose implementation details of the backend
The following types of exceptions are currently in use by the backend:
Raised when trying to edit or delete a message when it’s no longer possible.
Raised whenever a user does not have sufficient privileges to perform a certain action.
Raised whenever an operation is requested on an object that doesn’t exist.