[Seaside-dev] exception handler instance creation

[John O'Keefe]

Julian -
I'm back to work after a week and got a bad surprise.

Seaside-Core-jf.349 and the associated changes to other packages has
completely broken the VA Smalltalk port.  Our implementation of
Block>>#on:do: expects a class as its first argument (and in particular, the
class must be Exception or a subclass of Exception).  The same seems to be
true of VW.

But with Seaside-Core-jf.349 #on:do: is getting a WAExceptionHandler class
(or subclass of it) as the first argument <exception selector> and then with
Seaside-Core-jf.353 #on:do: is getting an instance of WAExceptionHandler (or
a subclass of it) as the first argument.  In either case, we fall over
because the WAExceptionHandler class/instance does not understand any of the
messages sent by #on:do: to the <exception selector>.

Since WAExceptionHandler is in the base, I assume it should be portable.

I have reverted to Seaside-Core-lr.348 and Seaside-Development-lr.53 for the
time being and things seem to be working OK again.

John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.


On Mon, Dec 29, 2008 at 3:12 PM, Julian Fitzell <jfitzell at gmail.com> wrote:

> I started writing some docs on the new exception handler interface. In
> doing so, I realized I hated the method name #exceptionToCatch so I
> changed that and then remembered that Lukas was asking for the
> exception handlers to implement #handles: and #, so that they can be
> used in place of an ExceptionSet as defined in the ANSI spec. So I did
> this too.
>
> This raised again the question of when an instance of our exception
> handlers should be created. If you look at the current implementation
> of #handleExceptionsDuring:context:, you will see that an instance is
> not actually created until an exception that this class handles is
> signaled. This requires a temporary variable and means that the
> instance does not have a chance to indicate whether it wants to handle
> the exception or not (whether they is a required feature or not is
> perhaps debatable... I dunno).
>
> The only reason I did this was to avoid the overhead of creating the
> instance when we don't need it but I'm wondering if this was a
> premature optimization and the implementation would be simpler if I
> didn't do it. #handleExceptionsDuring:context: would just become:
>
> #handleExceptionsDuring: aBlock context: aRequestContext
>   ^ (self context: aRequestContext) handleExceptionsDuring: aBlock
>
> And on the instance side we would have:
>
> #handleExceptionsDuring: aBlock
>        ^ aBlock
>                on: self
>                do: [ :exception |
>                        [ self handleException: exception ]
>                                on: Error
>                                do: [ :error | self internalError: error ] ]
>
> No temporary variable, instances can choose whether to handle
> exceptions if they want to, no risk of being unable to create an error
> handler when reporting an internal error.
>
> Am I right that this seems like the better option?
>
> Julian
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20081231/35a7d152/attachment.htm