Error Handlers versus Werkzeug Exceptions

[mitsuhiko]

Currently you can only declare error handler for Werkzeug exceptions. That's pretty much the case because what is not raised as a Werkzeug HTTP exception can't be catched. However since Python 2.4 is currently in the process of being phased out we could now finally make exceptions actual response objects if we prefer so it would make sense to keep that in mind and provide catching not only by code but also by any kind of instance check.

This also affects Werkzeug.

Related feedback issues:

• http://feedback.flask.pocoo.org/message/112

[adrianratnapala]

Perhaps I don't understand this issue, but maybe it should be closed. It seems like current flask versions allow error handlers for any kind of exception. By this I mean the following program runs without an error, there are all sorts of combinations and permutations which it doesn't test.

    import flask
    app = flask.Flask(__name__)

    @app.errorhandler(Exception)
    def handle_500(x=None):
            print "Trapped a python Exception!"
            return "app trapped", 200

    @app.route('/')
    def slash_view() :
            raise Exception("WTF?")

    c = app.test_client()
    resp = c.get('/')
    assert resp.data == "app trapped"
    assert resp.status_code == 200

[jeffwidman]

@untitaker Is this still relevant?

I don't fully understand the original issue, and unfortunately the linked-to feedback site is now dead.

[untitaker]

It's been a while, but I think the main idea here is to make HTTP exceptions fully fledged response objects. This is still valid.

The code for handling errors has been refactored to not make that much of a difference between HTTP and other exceptions, see #1291. But that's not the main point of this issue anyway.

[davidism]

HTTPException is a WSGI callable, so make_response handles it fine. Not sure what else needs to be done here. If this is still an issue it needs to be clarified before reopening.