Markus
can you read what I wrote.... I'm not teaching anything here related  
to first checking if a key exist or not, or
how to use a dictionary......

I'm teaching them to write tests and to write tests for a class that  
raises exceptions
you have to catch them and to cover the potential behavior of the  
class! This is not my wish or not to have exceptions, they are there  
and to cover the method behavior (because of different programming  
style) I have to cover them.

For example, what happens if we access an element at not existing index.

Stef


On 2 mars 06, at 14:14, Markus Gaelli wrote:

> 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...) ;-)

Again this is not the point, even if I agree on the use of ifAbsent:....
These are idioms and I'm talking here about test coverage!

Stef