About use of specific error
Julian Fitzell
julian at beta4.com
Thu Mar 2 16:51:31 UTC 2006
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
More information about the Squeak-dev
mailing list
|