Fix #941 -- allow errorhandlers for HTTPException #952

Closed
wants to merge 1 commit into
from

Projects

None yet

2 participants

@untitaker
Owner

Originally i intended to rewrite the error handling system to register an
error handler for each subclass of HTTPException on initialization of the
Flask object, removing the distinction between HTTP exceptions and other
exception types. However, with the current behavior of preferring the
first-registered handler when an error occurs, doing this without compromises
would require changing this to preferring the last-registered handler, a
backwards-incompatible change.

The following is a very minimal fix to only make Flask prioritize the user's
error handlers over others. I am not sure which performance implications this
has. Maybe a major rewrite of the error handling system is still desirable
(with more complex prioritization of errorhandlers -- something based on
"distance" in inheritance tree?), but at the moment i don't see a reason to do
so, given that the current system is primitive enough to be understandable,
while still usable.

mbr commented Jan 17, 2014

I'm in need of the same feature (and currently using a crude workaround), I'd love to see this fixed/merged.

@untitaker untitaker Fix #941 -- allow errorhandlers for HTTPException
Originally i intended to rewrite the error handling system to register
an error handler for each subclass of HTTPException on initialization
of the Flask object, removing the distinction between HTTP exceptions
and other exception types. However, with the current behavior of
preferring the first-registered handler when an error occurs, doing this
without compromises would require changing this to preferring the
last-registered handler, a backwards-incompatible change.

The following is a very minimal fix to only make Flask prioritize the
user's error handlers over others. I am not sure which performance
implications this has. Maybe a major rewrite of the error handling
system is still desirable (with more complex prioritization of
errorhandlers -- something based on "distance" in inheritance tree?),
but at the moment i don't see a reason to do so, given that the current
system is primitive enough to be understandable, while still usable.
ce10f84
Owner

Bump.

Owner

It seems like i duplicated #839 without realizing.

@untitaker untitaker closed this Mar 26, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment