[Seaside] Error handlers and critical sections
Ron at USMedRec.com
Fri Sep 14 02:08:04 UTC 2007
You are welcome!
> -----Original Message-----
> From: 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
> > 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:
> model doSomethingImportant
> now in my model
> [self useSomeResource. UnexpectedError signal] ensure: [self
> 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!
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the seaside