[Seaside] Error handlers and critical sections

[C. David Shaffer]

Ron Teitelbaum wrote:
> Hi David,
>
> I'm not sure I really understand your question.  There is a place in the
> code for handling exceptions.  If you make your own subclass of WASession
> then you can implement something like this: 
>
> withErrorHandler: aBlock
> 	"override and extend the basic seaside exception handling"
>
> 	^[[super withErrorHandler: [aBlock
> 		on: USMRSDBObjectRegister do: [:ex | self registerObject: ex
> object. ex resume]]]
> 		on: USMRSDBProxyReifier do: [:ex | self getObject: ex
> object. ex resume]]
> 		on: USMRSDBCurrentCommitManager do: [:ex | ex resume: self
> currentCommitManager].
> 	
>
>   
Yes!  I think that would be better...but with some minor differences.  
All of your handlers jump back into the signaling context (they are more 
like Notifications).  There's no unwinding to be done.  I'm talking 
about dealing with unexpected Errors.  Let me spell out an example:

MyComponent>>someCallbackMethod
    model doSomethingImportant

now in my model

MyModel>>doSomethingImportant
    [self useSomeResource. UnexpectedError signal] ensure: [self 
freeSomeResource]

This ensure: block will never run unless UnexpectedError is handled and 
that handler block exits.  This never happens if you use subclasses of 
WAErrorHandler to deal with errors...hence my unwindTo: attempt.   Your 
example led me to:

MySession>>withErrorHandler: aBlock
    ^super withErrorHandler: [aBlock on: Error do: [:ex | MyErrorLogger 
logError: ex].
            self returnResponse: ...]

Notice that in order to satisfy the requirement that the resource be 
freed the "self returnResponse:" must be outside the error handler so 
that the ensure: blocks gets invoked.  I think this is much better than 
my previous approach.  Thanks Ron!

David