[Seaside] Error handlers and critical sections

C. David Shaffer cdshaffer at acm.org
Thu Sep 13 20:16:38 UTC 2007

One challenge I've noticed in several of my recent apps is dealing with 
ensure: and critical: and friends in cases where Seaside's session error 
handler deals with an error.  (BTW, this is conceptually different than 
the case where we want to avoid call: inside such blocks.)  One has 
domain code called from a Seaside application and the domain code 
signals an otherwise unhandled exception.  These can be deep in the 
domain model where one shouldn't be conscious of Seaside at all.  
Unfortunately the converse is true as well, there is no way for UI level 
code to know of a protected block deep in the model.  What I'd like is a 
trick to write a Seaside exception handler that conceptually looks like:

handleError: anError
    anError unwindTo: the place where the session installed an error 
    display a document

I see an implementation of Exception>>unwindTo: but no senders or tests 
so I'm not sure it even works (or does what I think it does).

Of course, in response to this, many Seasiders already use 
critical:ifError: inside their model code but this ruins debugging.  The 
rough equivalent for ensure: is:

BlockContext>>reallyEnsure: aBlock
    self on: Error do: [:ex | aBlock value. ex pass]

I generally don't worry about non Error-type exceptions but these could 
be dealt with here as well.  Of course you can't retry, return etc. on 
the notification once you've finalized your resources.  Exceptions: with 
great power comes great responsibility ;-)

reallyEnsure:, like critical:ifError:, makes debugging a challenge since 
whatever resources are being freed by aBlock are needed if we want to 
raise a debugger.  In short the current behavior works great for 
debugging but in production leaves resources "unfinalized" whereas my 
solutions ruin debugging but make sure that finalization happens.

Anyone found a better solution?


More information about the seaside mailing list