Craig Latta wrote:

>> As it turns out, there just came in a new implementation and 
>> as a matter of fact I like it a *lot* - it is clean,
>> understandable and very well written. It is by far the best 
>> implementation I have seen... 
>
>    Why? Why is it better than the one I did? Is it the ANSI interface issue? 

IMHO, it's not an issue of ANSI compatibility, but of the basic semantics of 
exceptions. Permit me to make two comments; first, I personally find the usage 
pattern of,

    thisContext handle: signalName withDescription: descriptionString

(as used in CL's EH framework) pretty awful -- signals are not strings! 
I'm just more used to VW's paradigm of,

    aSignal raiseWith: someArg

like in every other ST-based exception implementation. (It's not important to 
me whether you use a class-based or instance-based signal model, just not a 
symbol-based one!)

Secondly, there seems to be some confusion or disagreement about the semantics 
of proceedability. In every other system I've ever used, proceedability is a 
property of an exception, not an argument to the raise: message as in Craig's

    situation handleWithParameter: arg description: descr andProceedability: aBoolean

This cost me alot of porting effort for code that assumed that certain exceptions 
were always proceedable.

I've looked over the Fourth Estate code, and am impressed. I'm planning to port 
the SMS database over to it, and hope to make some progress in adding EH to the 
system classes (for examples other than x/0, e.g., stream and file exceptions).
If there are any volunteers to help make the entire core of Squeak "exception-
friendly," I volunteer to try to coordinate effort so that we come up with 
something worthy of inclusion in the base system.

-- 
stp

Stephen Travis Pope | stp9 at cornell.edu | http://www.create.ucsb.edu/~stp