[TransWarp] Error handling in peak.web

Phillip J. Eby pje at telecommunity.com
Mon Aug 4 18:23:51 EDT 2003


Currently, peak.web has lousy handling for NOT_FOUND/NOT_ALLOWED, and no 
support for other kinds of HTTP errors (e.g. unsupported method, 
unauthorized, etc.).

Here's my current thinking for how the framework should handle errors:

* Drop the current interaction.notFound()/notAllowed() methods, as they 
were a hack that predated the ability to adapt errors to an 'errorProtocol'.

* Keep the convention of traversables' 'traverseTo()' method returning 
NOT_FOUND or NOT_ALLOWED, as this is a nice, simple convention that allows 
for non-publishing code to traverse to such places without error.

* Change TraversalContext so that the 'checkPreconditions()' method 
verifies whether the current location is NOT_FOUND/NOT_ALLOWED, and if so, 
raises an appropriate exception.

* Create a WebException base class, that implements IWebException, and 
accepts a traversal context as an initialization argument, along with maybe 
some keyword arguments for additional attributes such as a human-friendly 
message.  The exception would render itself using a template, designated by 
an attribute of the exception.  The base class would try to find a template 
designated 'peak.web/error_###' where '### would be the HTTP status code, 
or fallback to 'peak.web/standard_error'.  Subclasses could override this 
behavior by redefining that attribute using 'bindResource()'.

* Create NotFound, NotAllowed, and other WebException subclasses with 
appropriate HTTP status codes and templates.

* Change context.isNull() to an attribute (isNull).

That covers all the main framework changes, and moves the questions and 
issues entirely over to the realm of things like formatting the content of 
error messages.  (Well, there's also the issue of NotAllowed mapping to a 
login page and/or selecting its HTTP status code based on whether there's a 
logged-in user.  But that's something we'll need to tackle when we work on 
authentication services, maybe later this week.)

For now, I'm going to start work on the changes above, and whip up some 
ugly but functional error screens, then work with Ty later in the week to 
spruce them up a bit.





More information about the PEAK mailing list