Ok, I promised well over a month ago to start documenting some of the new bells and whistles in the Seaside 2.9 Alpha series. I thought I'd start things off with a discussion of the new exception handling mechanism.
Have you ever wanted to customize the look of Seaside's error pages? Want to send yourself an email whenever an exception is raised? Maybe save a copy of the image on errors so you can look at the stack later? It has been possible for ages to implement a custom error handling class for your Seaside application but the process was not necessarily obvious and you were limited to catching subclasses of Warning and Error. In the upcoming Seaside release, we have cleaned up the exception handling code to really simplify the error handlers that come with Seaside and to make your custom handlers simpler and more flexible.
Basic Usage
To create your own exception handler, the first question is what class to use as your superclass. If you are just interested in customizing the appearance of error pages or performing some additional action when an error occurs, you probably want to subclass WAErrorHandler. If your requirements are more complex, you may want to subclass WAExceptionHandler directly (see Advanced Usage below).
Subclassing WAErrorHandler
WAErrorHandler is already configured to handle Error and Warning and is a good starting point if you don't need to drastically change the error handling behaviour. In your custom subclass, you can implement #handleError: and #handleWarning: to define the behaviour you want in each case. The methods take the exception (either an Error or Warning respectively) as a parameter and should ultimately either resume the exception or return an instance of WAResponse. By default, both methods call #handleDefault: so you can provide common implementation there.
For example, assuming you had defined a routine to notify yourself of errors by email, you could provide an implementation like this:
handleError: anError
self notifyMeOfError: anError.
^ WAResponse new
internalError;
contentType: WAMimeType textPlain;
nextPutAll: 'Eek! An error occurred but I have been notified.';
yourself
Returning an HTML Response
You could of course provide an HTML response but you would want to make sure your HTML is valid (and that means a head, a title, a body, etc.):
handleError: anError
^ WAResponse new
internalError;
nextPutAll: '<html>
<head><title>Error!</title></head>
<body><p>An error occurred</p></body>
</html>';
yourself
If you want to use the Canvas API, you can subclass WAHtmlErrorHandler instead. Just implement #titleForException: and #contentForException:on: (it gets passed the exception and a canvas) and you're done.
Using Your Exception Handler
Once you have written your exception handler, you need to configure your application to use it. Open your web browser and navigate to the Seaside configuration page for your application. There you will find a preference called 'Exception Handler' and you should be able to choose your new class from the list.
Alternatively, from a workspace, execute something like:
(WAAdmin defaultDispatcher entryPointAt: 'myapp')
preferenceAt: #exceptionHandler put: MyHandlerClass
Advanced Usage
If your needs are more complex than the above, you may want to subclass WAExceptionHandler directly. An exception handler needs to do two things:
- choose which exceptions to handle
- define how to handle them
Selecting Exceptions
The easiest way to select which exceptions to handle is to implement #exceptionSelector on the class-side of your new handler (note: in Seaside 2.9a1 this method is named #exceptionsToCatch). Your #exceptionSelector method should return either an ExceptionSet or a subclass of Exception. You probably want to continue handling the exceptions handled by your superclass so your implementation might look like:
exceptionSelector
^ super exceptionSelector, MyCustomError
If your needs are somehow more complex, look at implementing #handles: and #, yourself on either the class- or instance-side, as appropriate (note: these two methods do not exist in Seaside 2.9a1).
Handling Exceptions
When an exception is signaled and your handler indicates (via #handles:) that it wishes to handle the exception, #handleException: is called and passed the signaled exception. To define your exception handling behaviour, simply implement #handleException: on the instance-side of your handler. Note that the same handler instance is used throughout a single HTTP request even if multiple exceptions are signaled.
The #handleException: method is expected to return a WAResponse object. It may also choose to resume the exception, cause the Request Context stored in its requestContext instance variable to return a response (by using #redirectTo: for example), or otherwise avoid returning at all; but if it returns, it should return a response.
Internal Errors
WAExceptionHandler also provides a class-side method called #internalError:context:. This method creates a new instance of the handler and calls #internalError:, which should generate a very simple error message. This method is used whenever the exception handling mechanism itself signals an error as well as any other place in the system where we cannot be certain that a more complex error handler will succeed. This method should not do anything that has potential to raise further errors.
Setting Up an Exception Handler
Exception handling for Seaside applications is set up by WAExceptionFilter (more information on filters in a later post) and you do not need to do anything else if you are using WAApplication and WASession. If you are implementing your own request handler, however, and want to use the exception handling mechanism, you will need to set up an exception handler yourself.
Although you could do everything yourself, the easiest thing is to call #handleExceptionsDuring:context: on your handler class, passing it the block you want wrapped in the exception handler and the current WARequestContext object. You can look at RRRssHandler for an example.
Examples
The Seaside distribution includes a few exception handlers that you can look at for examples of usage. Beware of WADebugErrorHandler and WAWalkbackErrorHandler, though, as they do crazy things to get debugging to work the way we want in Squeak; although they are well commented and may be interesting to look at, they are probably not good examples of general usage. The Seaside-Squeak-Email package includes WAEmailErrorHandler, an abstract class that can be subclassed and used to send an email whenever an error occurs.
3 comments:
i've just tried to set a different error handler in an application. In the configuration dialog i could find a way to do so but your example to do:
app preferencesAt: #exceptionHandler put: WADebugErrorHandler
doesn't work in Seaside 2.9a4. it seems only possible on the application's exception-filter (via "configuration at:..").
Splitting the configuration into cache, filter, application is a bit confusing. Do you plan to revert the behavior to what you explained in this post? Would be great if the application's configuration could be done with #preferenceAt:put: instead of querying for the filters/caches etc.
Karsten
We don't plan to revert the refactoring, no. Splitting exception handling into a filter rather than duplicating it in every request handler is sound. Clearly work still needs to be done in configuration area, though, and we know this.
The UI has only been modified the minimum necessary to make things work but is certainly no longer intuitive and needs work. The admin tools need to be improved so that common operations (like switching between deployment and development settings) are made easier.
We could probably add #exceptionHandler: to WAEntryPoint or something to make this particular change easier from a Workspace.
Finally, I have occasionally thought about keeping the configurations centralized in WAEntryPoint and having other things pull their values from there, but this is problematic in the case of, for example, WACache, which is used by both WAApplication and WASession. Both instances need the same configuration. How do you distinguish between them if they are stored in the Application?
Anyway, we know this is a pain point. Partly we're waiting to see how much of that is just that it's new and different, partly we're waiting for tools to catch up, and partly we're using it and getting feedback to see what else can be done.
This is a great bloog
Post a Comment