Comment 3 for bug 1256042

Revision history for this message
Christophe de Vienne (cdevienne) wrote :

Reproducing the comment I did on the abandoned patch, because it describes how I would solve this.

"""
Well, we can already override some things by redefining wsme.api.format_exception.

It can definitely be improved to be more accessible, allowing the application to provide an exception handler that will decide what kind of exception we have.

I do not think it is necessary to move entirely in the middleware, nor a good idea, because in the adapter we still have an easy access to the function definition,

So here is how I would do :

    Define a function signature for an exception handler. Something like handler(funcdef, exception_infos). The behavior of this handler is to :

* return a data struture to be sent back (as format_exception does), along with a specific error code if needed,
* raise an exception that will not be caught by the adapter

    Provide an api to set a handler as the default exception handler (wsme.api.set_default_error_handler).

    Add a new parameter to the generic expose that can set a specific error handler on a funcdef

    Modify the adapters to use the error handler defined on the funcdef, and if not defined the default one.

With this approach, doing what you want (let the middleware handle the exceptions) would be doable by setting a default exception handler that only reraise them.

It could also be done by making the default exception handler using options set on the funcdef to selectively reraise the client or server errors.
"""