On 2/7/06, Simon Belak <[EMAIL PROTECTED]> wrote: > > The more I think about it, the more I agree error handling is to > obtrusive right now. In particular I am bothered by situations where we > have a method completely oblivious to errors. Two possible scenarios can > ensue: > > 1) An exception is raised from within this method. > > 2) Validation (on input) fails. > > Solution to 1) is quite obvious. If the method doesn't want the error we > re-throw it to someone who will (e.g. CherryPy). But what about 2)? It > has been a standing practice in TG to re-call the method. However one > can make the same the same arguments against this behaviour.
Actually, it hasn't been a standing practice in TurboGears to capture exceptions, just validation errors. Here's how it has mutated over time: * 0.8 calls validation_error for errors (something that most people correctly dislike). It lets exceptions pass straight up * TG changed to pass validation errors through if there was an "errors" parameter * Then it changed to pass errors through all the time * Then the implicit database transaction stuff started catching exceptions, rolling back transactions and re-raising the exception * Now we get to the point where both errors and exceptions were passing through to the method. > > The best I can think of is to require some form of explicit conformation > that a method is aware of errors. This can be done in two ways: > > I) declaring tg_errors parameter, > II) using error_handler() decorator > > If neither of these conditions are met, error handling is taken to a > lower layer. For this to be consistent we would need to raise something > along the lines of NotImplementedError in case of 2). > > The only down-side to this aproach is a marginal boilerplate when using > very simple error handling schemes (e.g. where one uses validators > purely for conversions). 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? Kevin
