Kevin Dangoor wrote:
Actually, it hasn't been a standing practice in TurboGears to capture
exceptions, just validation errors.
That's what I meant, but didn't emphasies enough that my comment was
valid only for case 2).
As you can see from the above history, I've tended to treat validation
errors and exceptions differently. They seem like different beasts to
me. Validation errors occur through normal program operation, because
users don't always enter what you'd expect. Exceptions represent an
honest-to-goodness problem with the system.
Unless there are realistic use cases where people expect exceptions to
be raised with the same sort of frequency as validation errors, I'd
like to make sure that we handle validation errors as the primary case
and then exception catching as something that can be done via
error_handler(). Does that make sense?
I for one prefer a more generalised approach, unifying anything causing
ruptures in control-flow to be handled the same. I have already proposed
to Jeff to make Identity raise a "normal" exception and move the
(redirection) logic to an error handler but haven't heard from him yet.
In my mind, ideally any and all (authentication, input, model, ...
-related) error handling would be separated from actual [controller]
functionality. This has undoubtedly affected my implementation of error
handling, in retrospective I should have taken a more natural POV. I
would like this to be nicely integrated into the whole control-flow but
I certainly do not want to introduce something a majority of
users/developers will find cumbersome or not intuitive.
Since I am writing a wish list, I might as well mention this. I do not
like redirects. It would feel much more natural to just simply call a
method. If this method happens to be exposed, the URL should be
rewritten behind the scenes.
Simon