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

Reply via email to