About use of specific error

Markus Gaelli gaelli at emergent.de
Thu Mar 2 10:12:14 UTC 2006


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"?

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.

Using traits we shouldn't need the strange idiom to overwrite  
template or other superclass methods, that do not work in special  
subclasses, any more.
(It would be really tedious to enumerate all methods on all classes  
which do not work... ;-)

If the error string is telling me why the precondition fails, good.  
Why would I want to bother with different kinds of exceptions here?

By the way, I call a test, which tests the failing of a precondition,  
"pessimistic method example", but I am still open for a better name.
People did not like the name "counter example" or "negative example",  
though I still would prefer one of these names and I am about to  
rename...

Cheers,

Markus

On Mar 1, 2006, at 10:29 PM, stéphane ducasse wrote:

> Hi all
>
> I asked students of my lecture to write SUnit tests for some  
> collections and I noticed that in Squeak
> the collection library do not use specific exception but instead  
> use error:.
> The consequence is that it can be tedious to capture only specific  
> error. I was wondering what is the
> general feeling about this state. In VW they have various exception  
> that can be trapped more specifically.
>
> Stef
>




More information about the Squeak-dev mailing list