On 23/10/2010 05:39 PM, Darren New wrote:

> I don't think it's "expected vs severe", at least not in code where
> people have thought about it. It's more "errors you're likely going to
> want to handle right where they happen (such as not being able to open
> the file you're trying toopen)" vs "errors you likely have a more global
> catch for (such as divide by zero or out of disk space)".

Makes sense.

> The advantage of the exception mechanism is you can catch a bunch of
> exceptions anywhere in a bunch of called routines with one catch.

True enough.

[In Haskell, exceptions carry the disadvantage that due to lazy 
evaluation, it can be a tad unpredictable exactly when an exception will 
be thrown. Also, you can only catch these exceptions in the IO monad, 
which might be a very, very long way away from where the exception 
happened...]

> And I think that's where Java's checked exceptions concept fails: They
> explicitly turn the things you want to test for into exceptions, then
> require you to test for them anyway with a much more tedious and
> distracting syntax.

Heh, yeah, there is that. In all the Java code I've looked at, I don't 
think I've ever seen a try/catch block which actually *handles* an 
exception. They all just silently ignore it. (Then again, I haven't 
looked at a lot of exception code...)



There's a couple of people on the Haskell mailing lists who like to 
distinguish between "exceptions" and "errors" (and get all shirty when 
people claim that they're the same thing).

As far as I can tell, an "error" is a situation that arises due to a bug 
in your program, whereas an "exception" is when a situation is caused by 
external events that you can't control.

For example, division by zero or an invalid array index would be errors. 
(Your program should be constructed such that these never happen for any 
reason.) Trying to open a file that doesn't exist would be an exception. 
(Even if you check that the file exists, it could theoretically cease to 
exist by the time you go to open it.)

Some people have even gone as far as to suggest that it's a design flaw 
that errors can be caught. But of course, if it were not so then a mere 
coding glitch could crash a production system with no possibility of 
exiting gracefully, closing resources properly, logging what happened, 
or maybe, I don't know, restarting the failed operation?

(Ideally your program shouldn't contain any bugs. But if the program is 
critical enough, you really don't want it to just shut down because 
something bad happened. You might want to have it reset itself and try 
again - assuming that this is likely to produce a different result of 
course.)

Amusing thing: Last time I checked, a GHC program exits when thread #0 
exits. And if (say) thread #13 throws an exception which isn't caught, 
then thread #13 just exits, and the rest of the system keeps running. 
Isn't that fun? :-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message