[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
handler.
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?
David
More information about the seaside
mailing list