About use of specific error

I do not have a good internet connection here...

Good summary. I will digest it. You should explain to me (face to  
face your PreconditionError).
I think that the name is good and could be used in a lot of place  
where we do not really care of trapping the error.

>>>>
> We still haven't seen a compelling reason to introduce above  
> exception-classes. I thought you were proposing them but could not  
> find any argument for them.
> Reading your reply to Andreas it seems that you just wanted to  
> provoke... ;-)

Not really. As I said I was trying to educate my OO skills in face of  
exception. What is good to do or not.
Basically thinking aloud and I wanted to know what others were  
thinking. I often use squeak-dev to put some ideas on the wall and  
see what is left after some discussions.

> As I said, I think you provoked a fruitful discussion.

For me too :).

Stef

---

To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.

> From: stéphane ducasse
> In Java you  
> get really a lot of exceptions everywhere. The comparison is  
> interesting.

Java has had exceptions since the language was devised.  In Smalltalk, and especially in Squeak, exceptions are recent additions.  I suspect the reason that Smalltalk error handling has grown up the way it has, with variants of methods that don't throw the exception, is because error: didn't give the option of handling the problem - your code simply failed.  A Squeak exception hierarchy has not been constructed because we're still moving over from a 30-year-old legacy of throwing the user into the debugger rather than handling the exception somewhere in the call stack.

                - Peter

On 3-Mar-06, at 12:50 PM, Peter Crowther wrote:

>> From: stéphane ducasse
>> In Java you
>> get really a lot of exceptions everywhere. The comparison is
>> interesting.
>
> Java has had exceptions since the language was devised.  In  
> Smalltalk, and especially in Squeak, exceptions are recent additions.
Kinda; exceptions went into ParcPlace Smalltalk in about 1990; I  
remember spending several weeks implementing the primitives and VM  
stackhandling support in the BrouHaHa/Archimedes Smalltalk system.  
Squeak has had the basics of exceptions for quite a while too BUT it  
doesn't seem that anyone has really bothered to make much decent use  
of them. It's like proper Closures - we've had code to provide them  
for ages and yet haven't actually got them into the system properly.


> I suspect the reason that Smalltalk error handling has grown up the  
> way it has, with variants of methods that don't throw the  
> exception, is because error: didn't give the option of handling the  
> problem - your code simply failed.  A Squeak exception hierarchy  
> has not been constructed because we're still moving over from a 30-
> year-old legacy of throwing the user into the debugger rather than  
> handling the exception somewhere in the call stack.
I think that expresses it extremely well.

Raising an exception gives code higher up the food chain a chance to  
do something sensible without alarming a possibly naive  - or absent,  
think headless server - user without good cause. A good specific  
exception provides useful information just like a class does. How  
good would Smalltalk be if all our objects were the same and relied  
on having an instvar that was a string naming the class we should  
treat it as? I guess you could make a system like that but I doubt  
I'd enjoy using it.

My view is that low level code should raise exceptions (like say  
DiskGoneMissingException) than higher level code (like  
DatabaseAccessor) catches and handles. If there is something the  
handling cannot deal with then a new exception can be raised  
(DatabaseUnableToAccessException?) which the higher application might  
trap and handle by letting the user know of the problem. Users should  
never see walkbacks because of some low-level problem.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Government organization

Why an object must manage a situation (like
 an "exception") of other object?

The "self error:"... or "self xxx" mechanism
 fix problems to the context of incumbence.
Remember the old days when a customer
 report a problem when printing invoices
 and you browse the Invoice class to
 find and solve the problem?
Now people open the debugger...
 jump on the stack and "add code" anywhere...
 something is going wrong.

The use of exceptions let problems move
 outside the object of incumbence promoting the
 diffusion of emergences through the system (to
 other objects) & in the stack (to other levels
 of abstraction).

This difusion of emergences can only be tolerated
 on formal systems (written in any OOL), but not
 on organic & open systems like any smalltalk
 ambience.

The addition of exceptions to objects follow the
 same path that defining smalltalk as a language...
 you can agree on this pov, but there are other forms
 of using smalltalk...

In smalltalk we have exceptions AND other
 mechanisms; anyone can change and add
 other mechanisms according to local
 convenience. This situation can´t occur in Java
 world because people only want better exceptions
 (one solution for all).

best,
Ale.


----- Original Message -----
From: "Peter Crowther" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Friday, March 03, 2006 5:50 PM
Subject: RE: About use of specific error


> From: stéphane ducasse
> In Java you
> get really a lot of exceptions everywhere. The comparison is
> interesting.

Java has had exceptions since the language was devised.  In Smalltalk, and
especially in Squeak, exceptions are recent additions.  I suspect the reason
that Smalltalk error handling has grown up the way it has, with variants of
methods that don't throw the exception, is because error: didn't give the
option of handling the problem - your code simply failed.  A Squeak
exception hierarchy has not been constructed because we're still moving over
from a 30-year-old legacy of throwing the user into the debugger rather than
handling the exception somewhere in the call stack.

- Peter

Peter Crowther wrote:
> Java has had exceptions since the language was devised.
> In Smalltalk, and especially in Squeak, exceptions are
 > recent additions.  I suspect the reason that Smalltalk error
> handling has grown up the way it has, with variants of methods
 > that don't throw the exception, is because error: didn't give
 > the option of handling the problem - your code simply failed.
 > A Squeak exception hierarchy has not been constructed because
 > we're still moving over from a 30-year-old legacy of throwing
 > the user into the debugger rather than handling the exception
 > somewhere in the call stack.

I'm not sure I buy that. By your claim it should be the case that
instead of:

   map at: key ifAbsent:["something"]

one would use something like

   [map at: key] on: KeyNotFoundError do:[:ex| ex return: "something"].

Personally, I really don't want to move over to the latter style.

Cheers,
   - Andreas

On 3-Mar-06, at 3:22 PM, Andreas Raab wrote:

I can't see how what Peter wrote would be interpreted that way.

>
>   map at: key ifAbsent:["something"]
>
> one would use something like
>
>   [map at: key] on: KeyNotFoundError do:[:ex| ex return: "something"].

Obviously you *could* do that and if you wanted to explicitly handle  
a case of the key not being found in your collection it might be the  
best thing to do.  An 'ifAbsent:' block is great when there is a  
simple failure case and a simple failure response. I don't think it  
is so useful when things get more complex and there are many possible  
problems to handle.

For an in-memory OrderedCollection, at:ifAbsent: is extremely useful  
and since pretty much the only thing that can go wrong is the index  
being outside the collection bounds it covers the problem nicely. For  
a caching collection hiding a connection to a database I suspect that  
there are more things that can blow up and more nuanced responses  
that one would like to provide.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Grogs does it take to change a lightbulb?" "One. Something  
with manipulatory appendages will be along eventually."

tim Rowledge wrote:
By first saying "I suspect the reason that Smalltalk error handling has
grown up the way it has, with variants of methods that don't throw the
exception, is because error: didn't give the option of handling the
problem - your code simply failed." which (to me) implies that the
reason for having variants that take into account potential failure
(like Dictionary>>at:ifAbsent:) is simply the result of working around a
limitation and then going on to say "A Squeak exception hierarchy has
not been constructed because we're still moving over from a 30-year-old
legacy of throwing the user into the debugger rather than handling the
exception somewhere in the call stack." which seems to imply that we
ought to fix this by moving over to an exception handling style.

Cheers,
   - Andreas

On Fri, Mar 03, 2006 at 01:37:40PM -0800, tim Rowledge wrote:
I have a hunch that there is a human factors aspect of this also.
In practice, programming with exceptions seems to attract some of
the worst elements of human (and organizational) behavior.

I recently had the opportunity to be exposed to a Java project
in which the technical leadership proclaimed a requirement for
an "exception framework" and proceeded on that basis of that
"requirement" to produce a truly horrific spaghetti-mess of
slop that allegedly facilitated consistent exception handling.
This may sound like an extreme example, but I suspect that there
is something about clever exception frameworks that just brings
out the worst in human behavior.

Earlier in this thread, Markus Gaelli said "Exceptions are a way of
goto programming and can become quite hairy to use." This seems
about right, and I would only add that, as with all good things,
a little bit goes a long way.

I'm no expert in this stuff, I just can't help noticing that it
seems to attract bad behavior.

Dave

On 3-Mar-06, at 6:48 PM, David T. Lewis wrote:
>
> I have a hunch that there is a human factors aspect of this also.
> In practice, programming with exceptions seems to attract some of
> the worst elements of human (and organizational) behavior.
Can't argue with that; you only have to look at code to quickly gain  
that feeling. They're complicated. They're cool. They're so obviously  
clever stuff. You just have to use them all over the place to look  
like you really, really, know hard programming. It's part of being a  
hotshot c001d00d codemonkey.

Exceptions are really nothing more than a way of throwing your hands  
up and screaming
"somebody up there help me!" or a way to send a warning or progress  
signal up the callstack. I've noticed on a number of occasions that  
people tend to forget that 'up the callstack' part. The tricky bit,  
the stuff that causes much of the confusion is the strange and  
complex things you can do when handling an exception. Add in nesting  
and pass throughs and returnWith and it's no wonder it gets to be too  
much.

I claim there's a serious lack of tools to help with making use of  
exceptions which merely adds to the feeling of a big disconnect  
between the code raising the exception and a possible handler. Add in  
the inheritance that makes it possible for some code to signal  
FooBarException and for it to be handled in code that refers to  
WibbleException and you can lose anyone, even me. Oh and then there's  
bugs to toss in as well; non-proceedable exceptions that can proceed  
and so on.

I'm sure that it is possible to make a system for using exceptions  
that is clear, intelligable and well engineered. We just don't have  
one yet.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- If you called him a wit, you'd be half right.

Me too and this was not the question of my original email. I wanted  
to understand what heuristics
I could use when I'm programming to use (if any) exceptions in my  
code. And this meta question
was raised when I look at the tests the students were writing.

>
>   [map at: key] on: KeyNotFoundError do:[:ex| ex return: "something"].
>
> Personally, I really don't want to move over to the latter style.
>
> Cheers,
>   - Andreas

Indeed, I think that this was with the vision that Java was a  
language for internet (wild and unknown area) that lot of exceptions  
introduced and stressed.

Stef

> Indeed, I think that this was with the vision that Java was a
> language for internet (wild and unknown area) that lot of exceptions
> introduced and stressed.

The lack of contexts promotes the use of exceptions
 as a(the only) mechanism to act outside current method.

Ale.

----- Original Message -----
From: "stéphane ducasse" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Sunday, March 05, 2006 8:28 AM
Subject: Re: About use of specific error

> I'm sure that it is possible to make a system for
> using exceptions  
> that is clear, intelligable and well engineered. We
> just don't have  
> one yet.

Hm.  Well, I find Squeaks exceptions clear,
intelligble and well-engineered enough that they at
least seem to work (though I can't speak for the
innards).  Any programmer can learn about their
features in just a few minutes by simply
experiementing with them.

Have you used Java exceptions?  They unwind *before*
the handler (making debugging difficult).  They can't
ever resume, they've no defaultActions, no retries,
and no pass without rethrowing.  I find all of these
functions useful, so Java exceptions are woefully
underpowered and yet still quite confusing due to the
messy "checked" vs. "unchecked" business..

On 6-Mar-06, at 10:22 AM, Chris Muller wrote:
I'd accept that the exceptions are reasonably clear but the _system_  
for using them isn't. As I mentioned it is quite hard too work out  
for example where the exception you are raising might get handled.  
It's close to impossible to be sure which exceptions you might need  
to deal with.

>
> Have you used Java exceptions?  They unwind *before*
> the handler (making debugging difficult).  They can't
> ever resume, they've no defaultActions, no retries,
> and no pass without rethrowing.  I find all of these
> functions useful, so Java exception
I'm happy to say I've never had to do anything at all with java  
except drink it. It sounds awful.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RPM: Read Programmer's Mind

Sorry i missed this very interesting discussion, but some trivial thoughts
deserve to be recalled.

Sure exceptions were built in C++ java world...
Sure Smalltalk has alternate solutions thanks to block non local return.
( Compiler evaluate: 'bla + + bla' ifFail: [^nil] is even better example than
at:ifabsent: because it uses a non local block return).

However Markus, defensive programming is just a style, not a bad style, but
not the only one and not the most adequate in every case. There are many
cases where optimistic programming is better, when failure cases are so
unprobable that it would be a waste of time to repeatidly test costly
assertions (also better regarding volume of code). Exceptions find their
place here.

Of course, exception is particularly usefull for exception handling in long
call chains, where passing block or any other handler as extra argument is
the last thing wanted. I guess also very few Smalltalkers would be happy
testing for error return in the whole call graph like C-style code.

---------------------------------------

As a perfect example, we can think of arithmetic exception handling (overflow,
underflow, division by zero, domain error...). I would like to have these
exceptions in Squeak like they exist in VW. Unfortunately, Squeak use the
perverse IEEE NaN and Inf... In my opinion, this is rarely wanted and most
people would prefer a program to stop with an exception rather than having
these needless computations silently proceeding with NaNs. Beside it is then
difficult to find the originator of the error. Last, overflow does not really
match mathematical notion of infinity, i think confusion is dangerous here...

In some cases i would catch such an overflow and retry with another algorithm,
or switch from float32 to float64, or maybe my own LargeFloat like there are
LargeInteger... This is where i like having specific errors.

Maybe in another case, i can catch any kind of arithmetic error and restart
another algorithm, and then, yes Andreas, error hierarchy can be usefull
(though there are alternate solutions like handling error collections).

Then what are the guidelines that will prevent hundreds of Exceptions from
populating the hierarchy ? We should answer this question... unless we feel
comfortable with hundreds of classes.

To continue with arithmetic case, defensive tests are done either at VM level
and/or at hardware level, it would be so costly to duplicate them at
Smalltalk level ! Beside, no one is ready to transform all these + * - / into
plus:iffail: etc... Obviously, handling cannot be local and handler cannot be
passed as argument, exceptions are definitly a must here.

That also suggest one of the guidelines: the low level exceptions tested in
the VM should have a correspondance in the Error hierarchy (if they have a
failBlock argument, default block should signal a specific exception).

Lets return to arithmetic exceptions, I would really like to have them instead
of silent NaNs/Inf. NaN should be a way of handling arithmetic exception, but
not the preferred way. Anyone disagree ?

Nicolas

About catching exceptions in tests.
At Mercap, Hernan Wilkinson added a method to TestCase to simplify testing of exceptions, ie:

self should: [ "... " ]
raise: XxxException withSignalDo: [:signal | self assert: signal description notEmpty ].

It's very useful to do assertions on the exception :)

Here is the change set to implement it in Squeak (I have changed the selector to #should:raise:withExceptionDo: since in Squeak are exceptions not signals)

nicolas cellier wrote:
> As a perfect example, we can think of arithmetic exception handling (overflow,
> underflow, division by zero, domain error...). I would like to have these
> exceptions in Squeak like they exist in VW. Unfortunately, Squeak use the
> perverse IEEE NaN and Inf... In my opinion, this is rarely wanted and most
> people would prefer a program to stop with an exception rather than having
> these needless computations silently proceeding with NaNs. Beside it is then
> difficult to find the originator of the error. Last, overflow does not really
> match mathematical notion of infinity, i think confusion is dangerous here...

Interesting. In my use of floating point math the behavior in Squeak is
just exactly right ;-) I have never had the need for signaling
exceptions upon NaN or Inf. I guess that's the difference between
scientific computing and computer graphics ;-)

> Lets return to arithmetic exceptions, I would really like to have them instead
> of silent NaNs/Inf. NaN should be a way of handling arithmetic exception, but
> not the preferred way. Anyone disagree ?

Completely. Personally, I've yet to find a place where a floating point
exceptions would be more useful than silent NaNs or Infs (btw, I'm not
arguing that this has to be true in your case, just that it is in mine).

Cheers,
   - Andreas

On 17.03.2006, at 05:37, Diego Fernandez wrote:


In Squeak, there is already an SUnit extension for testing for  
description substrings (I think Ned added that):

self should: [....] raise: Error whoseDescriptionIncludes: 'string'


> Here is the change set to implement it in Squeak (I have changed  
> the selector to #should:raise:withExceptionDo: since in Squeak are  
> exceptions not signals)
>
> <SUnit exception assertions.1.cs>

Nice! I might add that to Squeak SUnit.

      Marcus

On Mar 17, 2006, at 3:57 AM, nicolas cellier wrote:

If you prefer corrupted data in your database over a a slower or  
error throwing program (*) you could always switch off the assertions  
in your production system later without any loss of performance:
http://www.whysmalltalk.com/articles/bykov/HitchHiker.htm

Implemented/ported by Romain Robbes:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-March/ 
075327.html

Cheers,

Markus

(*) You might be in a project phase, where your project leader  
politically prefers bad data in the db than walkback screens in the  
face of the end users.
At least I experienced such kind of a project once... ;-)