
Stop Catching Exceptions - paul_houle
http://gen5.info/q/2008/07/31/stop-catching-exceptions/
======
scott_s
Only catch errors that you know how to handle. If you don't know how to handle
it, it _should_ propagate higher up the stack, even if it kills the execution
of the program.

This implies that having a catch-all around your entire program is a _bad
idea_. Doing so loses the stack trace; you no longer know where the exception
was thrown from. I've had to debug programs that did this, and the first thing
I did was comment out the catch all so a simple stack trace could tell me
where to start looking.

In the compiler I'm writing right now, I do wrap the entire execution in a
try-catch block, but the only errors I catch are ones I call "user_error".
That represents an error in the input; I don't handle that kind of input on
purpose, and providing it is user error, not compiler error. I don't catch the
other kinds of exceptions I throw, which indicate what gcc calls "internal
compiler error." It's much easier for me to figure out what I did wrong that
way.

~~~
njharman
The language I use doesn't prohibit display/logging of full stack trace if you
catch exceptions. Or, trivially, catch/log in production catch/rethrow in dev.

What about daemons? large batch programs? I, personally, would rather have
them catch and alert(email, sms) unknown/unexpected exceptions continuing on
with what they can rather than simply die.

~~~
scott_s
That's assuming you _can_ continue on. Daemons and batch programs are unusual
in that every so often, there's a conceptual "wipe clean" and all prior state
doesn't matter. These are situations in which you know how to handle an error.

The alternative, to continue on in an error state without knowing how it will
effect execution, is worse.

------
nradov
The biggest problem we have dealing with checked exceptions in Java is that it
complicates interface inheritance when working with third-party class
libraries. What do you do if you have to write a concrete class to implement
an interface, but the interface's methods don't declare the exceptions you
need? The interface isn't under your control, and the interface method
signatures can't be changed anyway due to backward compatibility concerns.

What I usually do is cheat by catching the checked exception within the
method, and then throw it again by using exception chaining to wrap it into an
unchecked exception (RuntimeException). But it's hard to see that as a good
solution.

~~~
dkarl
"What I usually do is cheat by catching the checked exception within the
method, and then throw it again by using exception chaining to wrap it into an
unchecked exception (RuntimeException). But it's hard to see that as a good
solution."

By throwing RuntimeException you're saying "don't catch this," which I agree
is a bad thing, but any other kind of unchecked exception would be just as
bad. You implement a third-party interface so other people's code can call
methods on your object. If you throw exceptions they don't expect, then they
have no chance of catching them anyway, so what's the difference?

Checked exceptions are just another way of specifying the behavior of an
object so it can be handled predictably without knowing its precise type. If a
method doesn't let you throw an exception indicating failure, then the method
isn't supposed to fail, or it's supposed to report failure another way. If
that isn't reasonable for your implementation, then the library isn't suitable
for your needs. It isn't much different from the case where a method lacks
arguments that you need, or has a return type that is too restrictive for your
needs. If you can't adapt your code to fit the interface, you can't use it.

~~~
nradov
Ha ha. Nice theory, but sometimes in the real world you have no choice but to
use a particular third-party interface even if it isn't perfectly suitable.

------
dkarl
From the article: "With the hindsight of a decade, we can see that it’s a
disaster. The trouble is that every time you call a method that throws an
exception, you create an immediate crisis: you break the build. Rather than
conciously planning an error handling strategy, programmers do something,
anything, to make the compiler shut up."

Frankly, this is the weirdest complaint I've ever seen about checked
exceptions. If you're trying to build a system with crappy programmers, you're
kind of screwed anyway, but checked exceptions actually help you out quite a
bit, because you don't have a problem with stray exceptions taking down entire
subsystems. You might miss a lot of meaningful errors and get corrupted data,
but at least the system keeps running, and that's the most you can hope for if
your programmers are as crappy and lazy as the article describes.

And contrary to the article, few programmers are really that lazy and
irresponsible. In my experience, far more code is written by responsible
programmers who are inexperienced, rushed, or lacking a complete understanding
of the system. Checked exceptions catch a lot of normal programming errors and
result in more error cases being handled correctly. Like any other restriction
imposed by a programming language, they don't ensure perfect code, sometimes
they result in busy work, and crappy programmers will find crappy ways to work
around them, but IMHO they are helpful for most programmers.

~~~
wvenable
"You might miss a lot of meaningful errors and get corrupted data, but at
least the system keeps running, and that's the most you can hope for if your
programmers are as crappy and lazy as the article describes."

What? If I'm working with crappy programmers I don't want the system to keep
going and corrupting data -- in the vast majority of cases, that's the worst
possible result. Taking down the system with an nice error message and stack
trace is a much much better. Crappy programmers, in the presence of checked
exceptions, will handle exceptions with empty catch clauses (to prevent
breaking anything) and there will be no way to find that error when it
happens.

~~~
dkarl
It depends on what kind of application you're talking about. When I think of
hordes of crappy Java programmers, I think of enterprise web apps schlepping
around business data. In that case, I think it's better to corrupt a few
orders than to have hours of downtime every week.

~~~
Zak
Web applications should generally have some sort of generalized handler around
the entry point that sends back a web page saying "Something went wrong and we
didn't know what else to do, so we're showing you this error page. HTTP status
code 500." Production software should generally log a stack trace rather than
simply crashing, but checked exceptions make it harder to do that.

~~~
dkarl
A 500 error is a complete outage for every affected page. Most web app pages
contain a lot of boilerplate -- headers, graphics, navigation elements,
footers, and so forth, so a single error in a trivial component can cause an
outage for an entire application unless it is localized properly.

------
snprbob86
I agree completely with the spirit of this article.

Eric Lippert also provides an interesting view of the varieties of exceptions:
[http://blogs.msdn.com/ericlippert/archive/2008/09/10/vexing-...](http://blogs.msdn.com/ericlippert/archive/2008/09/10/vexing-
exceptions.aspx)

If you follow the philosophy of this article and classify exception's as Eric
suggests, you should be in pretty good shape.

------
chiffonade
> Use finally to stabilize program state when exceptions are thrown > Catch
> and handle exceptions locally when the effects of the error are local and
> completely understood > Wrap independent units of work in try-catch blocks
> to handle errors that have global impact

... isn't this what everybody does?

~~~
brlewis
I have the opposite impression, but maybe that's because when a Java library
does this right I never have to dive into the code.

