VAST 8 / Seaside Tips: Handling and Trapping Exceptions … And lots of Confusion!

I didn’t tell you the whole truth: John also expressed his doubts that SST would be responsible for the “500 Internal Server Error” pages, just as I had written in a previous post:

Let’s start by keeping SST from handling backend errors by returning HTTP 500 codes to the browser. The configuration of SST out of the box makes sense in a deployed app, where you may want to answer some error to the browser instead of boring your users with details they neither can do anything about nor are likely to understand.

In fact, I must admit that my assumption that these 500 codes stem from SST was probably wrong. I took some time to play with this error forwarding stuff and here’s what I’ve found:

  • The 500 pages are sent by Seaside, not by SST
  • SST can get in your way when you configure your Seaside Application to pop up a debugger when an exception occurs, but not by sending an 500 page. But only in some cases…

Let’s implement a tiny example component to see what I mean.

Create a WAComponent sublass, and implement the following two methods on the class side:

WAAdmin register: self
asApplicationAt: 'Sst 500 Internal Server Error'.

^ true

And the follwing rendering method on the instance side:

renderContentOn: html
html form: [
html submitButton
callback: [self crashWithZeroDivide ];
with: ‘Press me for an Error!’.]

That’s the whole implementation. The point here is that we need an exception to occur in some callback (not during rendering).

Now execute the registerAsSeasideRoot class method and configure the Application to use the WADebugErrorHandler exception filter.

This will work just fine, no matter if SST forwards or traps or eats or jumps on exceptions.

If I use the WAExceptionHandler as an exception filter, things seem to be different:

On my machine, the debugger comes up immediately when I press the submitButton. But only when I disable the Forwarding of Exceptions in the SST settings. If Forwarding is enabled, the browser will wait for a response “forever” and I will see no Seaside response at all.

But this may be another story and not related to SST at all. I need to investigate this a bit further, but now it’s time to get some work done….

And, of course, I need to re-read Julian’s excellent article on Seaside 2.9 Exception Handling.