Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Version 6 (modified by godoy, 13 years ago) (diff)


How does error handling work

WARNING: error handling is still in state of flux, the following page is primarily intended for developers.

WARNING2: for now, don't mix decorators and the syntax using tg_errors attribute. It won't work, yet. Even if in different modules in your system. -- SOLVED in r781

1 Validation errors


error handler -- method called when an error occurs.

Let foo be a function defined as

@validate(validators={"bar":validators.Int()}, "baz":validators.Int())
def foo(self, bar=None, bar=None):

1.1 Basics

Basic form of error handling is via decorator error_handler with error handler as argument:


my_eh can have an arbitrary signature, however one might wish to declare parameter tg_errors wherein errors (causing our error handler to be called) will be passed. Other parameters of interest are any named the same as arguments being validated, allowing us to fully reconstruct the original call (that failed validation). A more general approach would be using *identifier and identifier.

my_eh now looks something like:

def my_eh(self, tg_errors, bar):

Of curse nothing prevents us from using an existing (exposed) method as error handler.

A method can even be it's own error handler when error_handler is applied without any arguments:


or by declaring parameter tg_errors:

def foo(self, bar=None, tg_errors=None):

Mind, tg_errors should be a keyword argument, when used in this manner (since for valid input the method will not get re-called as error handler, hence tg_errors will not get passed in).

If no appropriate error handler is defined and validation failed, NotImplementedError? exception (from standard library) is raised.

1.2 Dispatch rules

What if we want to handle invalid baz-es differently than invalid bar-s? Fortunately for us, error_handler takes a second (keyword) argument rules, making it possible to influence selection of appropriate error handler (actually a limited interface to RuleDispatch?[1]). Rules are arbitrary logical Python expressions passed as lists. For example:

@error_handler(baz_eh, "'baz' in tg_errors")

The most specific applicable rule is selected, meaning if validation of baz fails, baz_eh will be called regardless of bar's state or in other words, bar_eh will be called if and only if validation of bar fails and baz passes.

Any number of calls to error_handler can be made with the same handler.

Since both arguments of error_handler are optional, specialisation is possible even when method is it's own error handler:

@error_handler(rules="'baz' in tg_errors")

2 Exceptions

2.1 Basics

Analogue to error_handler and tg_errors, exception_handler and tg_exceptions are defined.

If no appropriate exception handler is defined, exception is passed to a lower layer (e.g. CherryPy?).

2.2 Combining with error handling

One method can have any number of exception handlers and error handlers.

If having the same handler for errors and exceptions is desired, one can use errorhandling.register_handler which is similar to error_handler and exception_handler but without inherent specialisations.

3 Advanced topics

3.1 Utilities

3.1.1 bind_args

3.1.2 bind_rules

3.2 Generic functions

3.3 Continuations



Further reading


Generic functions