About use of specific error
Markus Gaelli
gaelli at emergent.de
Thu Mar 2 17:12:45 UTC 2006
Pascal, Lukas and Julian,
>> What is wrong with writing:
>>
>> IntervalTest >> testRemove
>> self should: [(1 to: 3) remove: 2] raise: Exception
>
> If you accidently write (note the typing error in the selector)
>
> IntervalTest >> testRemove
> self should: [(1 to: 3) remve: 2] raise: Exception
>
> you get a test that always succeeds.
>
and
> 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... :)
Thanks for clarifying. These counter examples make much sense.
So I'd suggest to come up with sth like:
PreconditionError >> error: aString
so that above became:
IntervalTest >> testRemove
self should: [(1 to: 3) remove: 2] raise: PreconditionError
What do you think? Could you agree to see this call as violating a
precondition?
Think of the receiver as the 0th parameter, in that case certainly
always wrong...aeh...is it?
Actually creating an empty interval seems to be allowed. So why
can't I remove an element of an interval with only one value?
Speaking more general, removing the last or first element of an
interval would keep the class invariant intact - if the interval has
at least one element of course.
Cheers,
Markus
More information about the Squeak-dev
mailing list
|