Julian -<div><br></div><div>I'm back to work after a week and got a bad surprise. </div><div><br></div><div>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.</div>
<div><br></div><div>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>.</div>
<div><br></div><div>Since WAExceptionHandler is in the base, I assume it should be portable.</div><div><br></div><div>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.</div>
<div><br clear="all">John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.<br>
<br><br><div class="gmail_quote">On Mon, Dec 29, 2008 at 3:12 PM, Julian Fitzell <span dir="ltr"><<a href="mailto:jfitzell@gmail.com">jfitzell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I started writing some docs on the new exception handler interface. In<br>
doing so, I realized I hated the method name #exceptionToCatch so I<br>
changed that and then remembered that Lukas was asking for the<br>
exception handlers to implement #handles: and #, so that they can be<br>
used in place of an ExceptionSet as defined in the ANSI spec. So I did<br>
this too.<br>
<br>
This raised again the question of when an instance of our exception<br>
handlers should be created. If you look at the current implementation<br>
of #handleExceptionsDuring:context:, you will see that an instance is<br>
not actually created until an exception that this class handles is<br>
signaled. This requires a temporary variable and means that the<br>
instance does not have a chance to indicate whether it wants to handle<br>
the exception or not (whether they is a required feature or not is<br>
perhaps debatable... I dunno).<br>
<br>
The only reason I did this was to avoid the overhead of creating the<br>
instance when we don't need it but I'm wondering if this was a<br>
premature optimization and the implementation would be simpler if I<br>
didn't do it. #handleExceptionsDuring:context: would just become:<br>
<br>
#handleExceptionsDuring: aBlock context: aRequestContext<br>
^ (self context: aRequestContext) handleExceptionsDuring: aBlock<br>
<br>
And on the instance side we would have:<br>
<br>
#handleExceptionsDuring: aBlock<br>
^ aBlock<br>
on: self<br>
do: [ :exception |<br>
[ self handleException: exception ]<br>
on: Error<br>
do: [ :error | self internalError: error ] ]<br>
<br>
No temporary variable, instances can choose whether to handle<br>
exceptions if they want to, no risk of being unable to create an error<br>
handler when reporting an internal error.<br>
<br>
Am I right that this seems like the better option?<br>
<br>
Julian<br>
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
</blockquote></div><br></div>