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

> Besides, for the Interval>>remove: example, the code would have been:
>
> Interval>> remove: anElement
>  "elements cannot be removed from an Interval"
>  ^self shouldNotImplement

So I need to browse the method and cannot see directly anymore what  
is going in the label of my walkback-window?

>
> Mind you, even in VW you have these calls of error:, and  
> shouldNotImplement is implemented that way...
> But why not implementing shouldNotImplement like:
>
> Object>> shouldNotImplement
>   ^ShouldNotImplementError raise

Why?

Cheers,

Markus
>
>
>
> Markus Gaelli wrote:
> 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
> >
>
>
> To help you stay safe and secure online, we've developed the all  
> new Yahoo! Security Centre.
>