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
|