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