John Sarkela wrote:
<...>

> Issues:
> 
> There are issues in the base image that need rectification and are the 
> motivation for the
> subject line of this message. In the Squeak exception mechanism, it is 
> never appropriate
> to send the #ifError: message, nor is it appropriate to ever set a 
> handler on Exception or
> Error unless the handler passes the exception after intercept.
> 
> (Note: consider the design intention behind the #ifCurtailed: message. 
> Almost
> certainly this is what users of #ifError: truly intend. But I'll leave 
> that discussion
> for a more complete description of the exception mechanism that I have 
> yet to write.)

Good to know *now* that there are design flaws: I'm somewhat surprised not
to find any warnings or comments about these issues in the image...

Just taken a look into the standard: there is no #ifError:, but #ifCurtailed: !
So using #ifError: is *not* portable (to give another argument to avoid it).

<snipped good example of how not to use exceptions>

But regarding Set>>add: as an example of other ANSI defined as 'undefined'
things:

Here I don't like to have as IllegalCollectionValueError>>defaultAction to
silently make it work however.
Assumed there is a programmer relying on an ANSI 'undefined' behavior to be
defined however he/she wants it: I'd prefer to *force* him/her to state it
*explicitly* (and therefore visible) in the calling code by installing an
appropriate handler.

Going this way it would probably be best to fix Glorp then in this concrete
example (to avoid a special handler).


Greetings,

Stephan
-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3