Markus Gaelli wrote:
> Hi Pascal,
> 
>> It would be easier to catch and therefore to test with a specific  
>> subclass of Exception.
> 
> 
> What is wrong with writing:
> 
> IntervalTest >> testRemove
>     self should: [(1 to: 3) remove: 2] raise: Exception

Presumably because the class you are testing may be calling another 
class to do some work and *it* might be raising an exception.  It's a 
little hard to imagine a good example for this particular case but 
perhaps it's looking up a preference and Squeak can't find the 
Preferences file.  But if that preferences file *was* there, then that 
could would happily carry on without raising an exception.  Your test 
*should* be failing, it's just getting disguised.

But I do agree there is some difference between, say, a network 
exception that might prompt you to retry your behaviour vs. an exception 
saying "you're using the code wrong, buddy!".  In the latter case, there 
does seem to be less advantage to having specific subclasses.

We should keep in mind that subclassing exceptions is not just to 
provide the ability to differentiate between them when they are caught 
though.  One of the great powers of exceptions here is having the 
ability to specify default behaviour.  This allows the programmer to 
catch all exceptions during debugging but may in fact allow the program 
(or the user) to decide to continue on with a valid default when the 
program is really running.

Sorry for the stream of consciousness email... :)

Julian