[rastapasta42]

You would be surprised by the amount of mission-critical code which runs on Flask.

Flask is a great library which gets out of your way - I find it a joy to use compared to Django.

Although there are some dark sides, particularly with how Flask interacts with Werkzeug during exceptions when you need CORS (for example, we can't overwrite exception page's Access-Control-Allow-Origin headers with @app.after_request since these headers are set by Werkzeug and can't be overwritten in Flask).

This prevents us from levering Flask's default except handler in certain environments which require custom headers for exception handling page.

[Nicholas_C]

> Flask is a great library which gets out of your way - I find it a joy to use compared to Django.

Agreed. I found Flask after being really annoyed with learning Django. Flask + Heroku is an awesome combo for the hobbyist like myself.

[mvolfik]

How are these set in werkzeug? Sound like you would be using the werkzeug dev server then...

But this works for me:

    @app.errorhandler(ApplicationError)
    def handle(e):
        resp = e.args[0]
        resp.headers["Access-Control-Allow-Origin"] = "..."
        resp.status_code = 500
        return resp

    @app.route("/err")
    def err():
        raise ApplicationError(jsonify({"reason": "test"}))

[rastapasta42]

I'm aware about the ability to overwrite error handler with a custom code, but Werkzeug's handler already supports pretty stack traces and much more, and I would rather not re-invent the wheel from scratch.

I was talking about using werkzeug's builtin exception handler but with custom headers - which doesn't appear to be supported.

[mvolfik]

that is not supported. But why would you want to serve that with CORS headers? It's only meant to be displayed in the browser and in dev environment, not production