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.
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).
Thoughts, suggestions?
Cheers,
Simon
