[Seaside] Exceptions handling

[Avi Bryant]

On Tue, 22 Mar 2005 17:31:23 +0000, David Shaffer <cdshaffer at acm.org> wrote:

> >WAClosureTest on 'go with ensure' prints:
> >'ensure'
> >'a 1' 'ensure'
> >'b 2' 'ensure'
> >'c 3' 'ensure'
> >
> >Is that right?
> 
> I'll let Avi address this.  I think it's fine...

It's "fine" in that it's what I would expect the implementation to do,
but I would say that example is more one of "don't do this" than
anything else.  I recommend that any #ensure: use within Seaside does
*not* wrap a send to #call:.  Otherwise you're almost certainly bound
to get confusing results, one way or another.
 
In general, the interaction between #ensure: and continuations is an
unsolved and much debated problem.  It's the main reason that Common
Lisp has never adopted call-with-current-continuation from Scheme, and
conversely why Scheme doesn't have CL's unwind-protect (which is
equivalent to #ensure:).  See, for example,
http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations/orig.html

> I think this behavior can be expected since Seaside wraps your callback
> handling in an error handler.  So, in non-deployment mode you have the
> equivalent of this:
> 
> [ [1/0] ensure: [Transcript show: 'err1'; cr] ] on: Error do: [:ex |
> Transcript show: 'err2'; cr]
> 
> Notice that err2 prints first.  That's basically what you're seeing in
> Seaside. Tthe equivalent of show: 'err2' is that the Seaside error
> handler, WAWalkbackErrorHandler, is starting a new render loop to render
> the stack trace page.  Basically you are still inside the do: argument
> block until you debug the app.  Then you exit that block and ensure:
> does its work. 

Right.

> My guess (completely untested) is that if you switch to
> deployment mode you'll see your ensure block run as expected.

Hm.  No, I don't think so, because the deployment mode still handles
errors, it just prints a less informative message when you run into
them.

Avi