Hi Stef,

>> let's have a look a the following example:
>>
>> 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 would claim that almost all (happy for any counter example) uses  
>> of "self error:" are indicating that some (maybe implicit)  
>> precondition fails.
>> Being radical I would say in above situation the precondition just  
>> fails always, meaning that this method would never make sense to  
>> be called on Intervals.
>
> But I'm not talking about that in particular.
>
> Dictionary>>at: key
> 	"Answer the value associated with the key."
>
> 	^ self at: key ifAbsent: [self errorKeyNotFound]
>
> errorKeyNotFound
>
> 	self error: 'key not found'
>
> errorValueNotFound
>
> 	self error: 'value not found'
>

as I answered Boris:
I am still not convinced that the idiom of "first (possibly) hitting  
the wall, and then asking for the door" is a good one to teach  
students programming.
I think it would be better to teach students a _defensive_ way of  
programming, that is to ask first, if everything is ok, using some  
boolean queries and if these queries do not exist, let them write  
these queries and _not_ exception hierarchies.

So in your examples I would teach to use
	Dictionary >> includesKey:
	Dictionary >> includes:
_before_ calling
	Dictionary >> atKey:
	Dictionary >> keyAtValue:
respectively.

Alternatively
	Dictionary >> at: key ifAbsent: exceptionBlock
	keyAtValue: value ifAbsent: exceptionBlock
are certainly often our best friends here - without having the need  
for any "real" exceptions (and also too much asking before...) ;-)

Cheers,

Markus