|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |