On 2 mars 06, at 18:55, Andreas Raab wrote:

> stéphane ducasse wrote:
>>> Intervall >> remove: anElement
>>>     self error: 'elements cannot be removed from an Interval'
>>>
>>> What do you mean with "trapped more specifically"?
>> Not for this one
>>     but
>>         IndexNotFoundError
>>         KeyNotFoundError
>>         SubscriptOutOfBoundsError
>
> I have often wondered about the usefulness of such hierarchies. The  
> way I look at it, an exception hierarchy is useful if and only if  
> one has a need to handle the exceptions individually.


Exact! I do not know if people ever tried to catch these ones. I have  
the impression that this is really an idiom in Smalltalk. In Java you  
get really a lot of exceptions everywhere. The comparison is  
interesting.
I do not have the taste right now to have strong arguments pros or  
cons. This is why I asked to see the reaction and
improve my exception taste.

> And what's interesting here is that in particular the above seem to  
> be cases where nobody ever handles them (and doesn't have the need  
> to since there are always variants that explicitly avoid the error  
> condition like #at:ifAbsent: #removeKey:ifAbsent: etc). Therefore  
> I'd claim that if you have a case where a client handles an  
> exception by looking at the error text, then by all means, make it  
> a separate entity. But otherwise, don't make the system more  
> complex than it needs to be.

Yes. Now the difficulty is to know when you are designing your system  
in advance how your clients will use it.
May be KISS and wait and see.

One exception that I like to trap was the "filein error" that you  
would get when you define a class by sending a message
to a superclass that does not exist :). In VW it lets me load broken  
or partial code that I just need to browse and analyze but not run

Stef