If an exception is raised during the processing of a handler method, it's always handled gracefully, returning a response object that contains the error message and (when is_debug == True) the traceback. It's fine most of the time, unless the exception is "unexpected". Such exceptions will result in a Server Error (500) response.
The problem I have with this behavior is that the exception is "silenced", especially in production where is_debug will be set to False, effectively hiding important debugging information that is required to track down a bug or system failure.
There's always the option of overriding the bubble_exceptions method on all endpoints and handle the exceptions myself using a middleware, but I find such a solution to be noisy and cumbersome.
I suggest to simply log the exception using the standard logging library in the restless.resource.Resource.handle method.
I can provide a patch.
Thanks!
If an exception is raised during the processing of a handler method, it's always handled gracefully, returning a response object that contains the error message and (when is_debug == True) the traceback. It's fine most of the time, unless the exception is "unexpected". Such exceptions will result in a Server Error (500) response.
The problem I have with this behavior is that the exception is "silenced", especially in production where is_debug will be set to False, effectively hiding important debugging information that is required to track down a bug or system failure.
There's always the option of overriding the bubble_exceptions method on all endpoints and handle the exceptions myself using a middleware, but I find such a solution to be noisy and cumbersome.
I suggest to simply log the exception using the standard logging library in the restless.resource.Resource.handle method.
I can provide a patch.
Thanks!