On #ifError: considered harmful was Re: Set>>add:
Stephan Rudlof
sr at evolgo.de
Wed Nov 13 11:51:45 UTC 2002
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
More information about the Squeak-dev
mailing list
|