6 ms·

Stop Catching Exceptions

32 points by paul_houle 18y ago

chiffonade 18y ago
> 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 18y ago
  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.
- paul_houle 18y ago
  i wish it was
scott_s 18y ago
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.
- markessien 18y ago
  If you get an error, but the error is within a closed subset of your program, you should not propagate the error upwards. Let's say you are sending data to another program on the same system. The other program could do many things, and could send answers you do know how to reply to. The error is in your function and in your function alone - you should simply exit the function without exiting the program. The range of errors are limited, and none of them are life threatening, but only your function knows that, the rest of the program is unaware of what the unknown error means. Propagating errors upwards like you say breaks functionality encapsulation.
  - scott_s 18y ago
    What you said does not contradict my statement: only catch errors you know how to handle. You presented a situation in which you did know how to handle the error. But if you don't know how to handle it, you should still throw it up, even if it breaks functionality encapsulation. This will likely crash the application, but the source of the error will be easily traceable, and the underlying problem can be fixed.
    - markessien 18y ago
      Can you give some examples of errors that should be thrown upwards? What percentage of errors in a program belong to this group?
      - scott_s 18y ago
        The most obvious to me is when you know something should be one of a finite set of values, and its actual value is not in that set. In my compiler, I have to classify array accesses as either a row or a column access. After a certain point, if it's neither (unitialized), then it's a serious error, I can't continue, and I throw an exception. I have similar situations when I deduce the types of an expression. Since I perform transformations on code, I also expect to find certain variables at certain places - if I can't find it anywhere, then I throw an exception. Some of these are exceptions that I can recover from in that while the compilation is broken, I can still continue to find more errors. Others are show stoppers. I encounter these kinds of errors every time I have to do any decision based on these properties, which is often.
- njharman 18y ago
  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 18y ago
    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 18y ago
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 18y ago
  "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 18y ago
    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 18y ago
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 18y ago
  "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 18y ago
    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.
snprbob86 18y ago
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-exceptions.aspx http://blogs.msdn.com/ericlippert/archive/2008/09/10/vexing-... If you follow the philosophy of this article and classify exception's as Eric suggests, you should be in pretty good shape.

32 points by paul_houle 18y ago

> 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 18y ago
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.
paul_houle 18y ago
i wish it was

scott_s 18y ago

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.

markessien 18y ago
If you get an error, but the error is within a closed subset of your program, you should not propagate the error upwards. Let's say you are sending data to another program on the same system. The other program could do many things, and could send answers you do know how to reply to. The error is in your function and in your function alone - you should simply exit the function without exiting the program. The range of errors are limited, and none of them are life threatening, but only your function knows that, the rest of the program is unaware of what the unknown error means. Propagating errors upwards like you say breaks functionality encapsulation.
- scott_s 18y ago
  What you said does not contradict my statement: only catch errors you know how to handle. You presented a situation in which you did know how to handle the error. But if you don't know how to handle it, you should still throw it up, even if it breaks functionality encapsulation. This will likely crash the application, but the source of the error will be easily traceable, and the underlying problem can be fixed.
  - markessien 18y ago
    Can you give some examples of errors that should be thrown upwards? What percentage of errors in a program belong to this group?
    - scott_s 18y ago
      The most obvious to me is when you know something should be one of a finite set of values, and its actual value is not in that set. In my compiler, I have to classify array accesses as either a row or a column access. After a certain point, if it's neither (unitialized), then it's a serious error, I can't continue, and I throw an exception. I have similar situations when I deduce the types of an expression. Since I perform transformations on code, I also expect to find certain variables at certain places - if I can't find it anywhere, then I throw an exception. Some of these are exceptions that I can recover from in that while the compilation is broken, I can still continue to find more errors. Others are show stoppers. I encounter these kinds of errors every time I have to do any decision based on these properties, which is often.
njharman 18y ago
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 18y ago
  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 18y ago

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 18y ago
"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 18y ago
  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 18y ago

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 18y ago
"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 18y ago
  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.

snprbob86 18y ago

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-exceptions.aspx http://blogs.msdn.com/ericlippert/archive/2008/09/10/vexing-... If you follow the philosophy of this article and classify exception's as Eric suggests, you should be in pretty good shape.