5 ms·

RuntimeExceptions – To try-catch or not to catch?

27 points by perseus323 14y ago

traxtech 14y ago
In "real life" you catch runtime exceptions everywhere, because well, that's what third-party libraries often throws. I hate that, especially when these exceptions occurs in prod...
smoyer 14y ago
I'd love to be able to say I never have to catch RuntimeExceptions, but that would require that library and framework writers actually use checked exceptions when they should. The best example I can think of (and one that a JEE developer who uses JPA should be intimately familiar with) is that that the getSingleResult() method of the Query object in JPA throws RuntimeExceptions if zero or more than one result is returned.
- traxtech 14y ago
  And that's just one example amongst thousands of others :( javax.xml.ws.WebServiceException is also quite commonly annoying.
- suresk 14y ago
  The funny thing is, in almost any discussion about exception handling in Java, I hear the opposite complaint - too many APIs throw checked exceptions. I've been leaning more and more to liking it when APIs force consumers to at least be aware of known error conditions. Scala's Option type is another example of this - I've watched people be sort of annoyed by it at first, but it tends to really improve the reliability and overall quality of the code when it is used properly.
  - traxtech 14y ago
    Reliability on prod is imho a big win for the less-sexy checked exceptions.
  - lucian1900 14y ago
    Scala's Option is a monad, so it's very easy to chain several actions and safely decide if they all succeeded or failed. It doesn't compare with checked exceptions at all.
Uchikoma 14y ago
Runtime exceptions can turn into ugly production problems. I prefer a combination of Validation, Success/Failure, Some/None and checked exceptions.
pjungwir 14y ago
I think it's normal to catch RuntimeExceptions at a high level in your outer loop so you can log it, email it, or whatever, and not let your process die. This is what servlet containers like Tomcat are doing. I agree that catching them elsewhere raises suspicions. The author's example seems fine, provided they can distinguish an exception-from-a-B-transaction vs an exception-from-a-program-bug. If I were him, I'd keep that checkFormat method, but only call it when I catch a RuntimeException, to see if it's something to worry about or not. I was pleased that the author appears to have tested the performance of both approaches and is making a decision based on real numbers.
jhdevos 14y ago
Of course, there are also the RuntimeExceptions that should really have been just Exceptions. These are often thrown by libraries where new features required exceptions to be thrown, but they couldn't be checked exceptions because the interface had to remain backwards compatible... Or, of course, libraries written by people who just don't like checked exceptions at all.
rfxtr 14y ago
Awesome post. Thanks for posting. This was my interview question.
aardvark179 14y ago
I strongly agree that runtime exceptions are the right way to go for certain rare events, see for example the new Java 8 addExact and multiplyExact methods which throw exceptions on overflows. These will not happen often but making them an exception allows implementers of languages with numeric type promotion to remove their own checks, and for the JIT to optimise the entire exception away in most cases.
jontro 14y ago
It seems that the debate about using checked or unchecked exceptions is still running. This article has some more insights I think http://jyops.blogspot.se/2012/03/why-should-you-use-unchecked-exceptions.html http://jyops.blogspot.se/2012/03/why-should-you-use-unchecke...
stickfigure 14y ago
Sorry, this is not going to be gentle. This post is clearly written by someone who is new to Java, and starts with the antique assumption that the runtime/checked exception dichotomy is a good idea. After nearly two decades of experience, programmers and language designers have resoundingly voted this language design feature to be a failure. A little bit of experience catching idiotic exceptions like UnsupportedEncodingException and you start to see why. But it goes deeper than just bad design in the standard libraries - checked exceptions fundamentally violate interface encapsulation - try throwing a meaningful exception through Runnable or Iterator. The net result is stacktraces with dozens of wrapped exceptions that destroy any hope of meaningfully handling known error conditions. Stop it. JUST STOP IT. Checked exceptions have wasted hundreds of hours of my time, not just writing lame wrappers so that I don't have to type try/catch on every line of code, but also by making debugging and error handling five times more painful than it should be. If you're still touting checked exceptions in 2013, you are part of the problem. Stop it. Java needs to evolve, and your fresh-from-1995 opinion is not helping. TL;DR: Of course you should catch RuntimeExceptions. There should be no other kind of exception.
- pifflesnort 14y ago
  > checked exceptions fundamentally violate interface encapsulation You have that backwards. Unchecked exceptions will blithely and without warning completely explode your stack. They're the Atomic Goto. The only way to know whether you're going to get one is to check the documentation, where you can only hope that the API author -- and the author of every API he calls -- has actually documented the exceptions that get thrown, because the compiler will be no help whatsoever, and god forbid an API start throwing an exception later. > ... try throwing a meaningful exception through Runnable or Iterator. If you pass around an object that conforms to Iterator, but throw an exception within it, __YOU'RE BREAKING THE API CONTRACT.__ Anyone that relies on the API contract of the Iterator class could have their state completely walloped by the Atomic Goto you inserted with a runtime exception. > Stop it. JUST STOP IT. Checked exceptions have wasted hundreds of hours of my time, not just writing lame wrappers so that I don't have to type try/catch on every line of code, but also by making debugging and error handling five times more painful than it should be. This makes no sense, because more work is required without checked exceptions. Without checked exceptions: - You must check the API docs for every line of code you write to see if it will throw an exception, and if so, what types. - If it throws an exception, you must either add a try/catch block to handle the error appropriately (or wrap it in a new exception type), or you must add documentation to your method to declare that it will bubble up an exception, and of what type. - If new exception types are thrown by underlying code, nothing tells you until your application explodes. With checked exceptions: - The compiler tells you what exceptions code throws, and of what type. - If it throws an exception, you must either add a try/catch block to handle the error appropriately, or declare it in the method prototype. The IDE will do both of these things for you. - If new exception types are thrown by underlying code, the compiler will warn you. > If you're still touting checked exceptions in 2013, you are part of the problem. Stop it. Java needs to evolve, and your fresh-from-1995 opinion is not helping. Stop advocating broken API design and ignorance of API invariants.

27 points by perseus323 14y ago

In "real life" you catch runtime exceptions everywhere, because well, that's what third-party libraries often throws. I hate that, especially when these exceptions occurs in prod...

smoyer 14y ago

I'd love to be able to say I never have to catch RuntimeExceptions, but that would require that library and framework writers actually use checked exceptions when they should. The best example I can think of (and one that a JEE developer who uses JPA should be intimately familiar with) is that that the getSingleResult() method of the Query object in JPA throws RuntimeExceptions if zero or more than one result is returned.

traxtech 14y ago
And that's just one example amongst thousands of others :( javax.xml.ws.WebServiceException is also quite commonly annoying.
suresk 14y ago
The funny thing is, in almost any discussion about exception handling in Java, I hear the opposite complaint - too many APIs throw checked exceptions. I've been leaning more and more to liking it when APIs force consumers to at least be aware of known error conditions. Scala's Option type is another example of this - I've watched people be sort of annoyed by it at first, but it tends to really improve the reliability and overall quality of the code when it is used properly.
- traxtech 14y ago
  Reliability on prod is imho a big win for the less-sexy checked exceptions.
- lucian1900 14y ago
  Scala's Option is a monad, so it's very easy to chain several actions and safely decide if they all succeeded or failed. It doesn't compare with checked exceptions at all.

Uchikoma 14y ago

Runtime exceptions can turn into ugly production problems. I prefer a combination of Validation, Success/Failure, Some/None and checked exceptions.

pjungwir 14y ago

I think it's normal to catch RuntimeExceptions at a high level in your outer loop so you can log it, email it, or whatever, and not let your process die. This is what servlet containers like Tomcat are doing. I agree that catching them elsewhere raises suspicions. The author's example seems fine, provided they can distinguish an exception-from-a-B-transaction vs an exception-from-a-program-bug. If I were him, I'd keep that checkFormat method, but only call it when I catch a RuntimeException, to see if it's something to worry about or not. I was pleased that the author appears to have tested the performance of both approaches and is making a decision based on real numbers.

jhdevos 14y ago

Of course, there are also the RuntimeExceptions that should really have been just Exceptions. These are often thrown by libraries where new features required exceptions to be thrown, but they couldn't be checked exceptions because the interface had to remain backwards compatible... Or, of course, libraries written by people who just don't like checked exceptions at all.

rfxtr 14y ago

Awesome post. Thanks for posting. This was my interview question.

aardvark179 14y ago

I strongly agree that runtime exceptions are the right way to go for certain rare events, see for example the new Java 8 addExact and multiplyExact methods which throw exceptions on overflows. These will not happen often but making them an exception allows implementers of languages with numeric type promotion to remove their own checks, and for the JIT to optimise the entire exception away in most cases.

jontro 14y ago

It seems that the debate about using checked or unchecked exceptions is still running. This article has some more insights I think http://jyops.blogspot.se/2012/03/why-should-you-use-unchecked-exceptions.html http://jyops.blogspot.se/2012/03/why-should-you-use-unchecke...

stickfigure 14y ago

Sorry, this is not going to be gentle. This post is clearly written by someone who is new to Java, and starts with the antique assumption that the runtime/checked exception dichotomy is a good idea. After nearly two decades of experience, programmers and language designers have resoundingly voted this language design feature to be a failure. A little bit of experience catching idiotic exceptions like UnsupportedEncodingException and you start to see why. But it goes deeper than just bad design in the standard libraries - checked exceptions fundamentally violate interface encapsulation - try throwing a meaningful exception through Runnable or Iterator. The net result is stacktraces with dozens of wrapped exceptions that destroy any hope of meaningfully handling known error conditions. Stop it. JUST STOP IT. Checked exceptions have wasted hundreds of hours of my time, not just writing lame wrappers so that I don't have to type try/catch on every line of code, but also by making debugging and error handling five times more painful than it should be. If you're still touting checked exceptions in 2013, you are part of the problem. Stop it. Java needs to evolve, and your fresh-from-1995 opinion is not helping. TL;DR: Of course you should catch RuntimeExceptions. There should be no other kind of exception.

pifflesnort 14y ago
> checked exceptions fundamentally violate interface encapsulation You have that backwards. Unchecked exceptions will blithely and without warning completely explode your stack. They're the Atomic Goto. The only way to know whether you're going to get one is to check the documentation, where you can only hope that the API author -- and the author of every API he calls -- has actually documented the exceptions that get thrown, because the compiler will be no help whatsoever, and god forbid an API start throwing an exception later. > ... try throwing a meaningful exception through Runnable or Iterator. If you pass around an object that conforms to Iterator, but throw an exception within it, __YOU'RE BREAKING THE API CONTRACT.__ Anyone that relies on the API contract of the Iterator class could have their state completely walloped by the Atomic Goto you inserted with a runtime exception. > Stop it. JUST STOP IT. Checked exceptions have wasted hundreds of hours of my time, not just writing lame wrappers so that I don't have to type try/catch on every line of code, but also by making debugging and error handling five times more painful than it should be. This makes no sense, because more work is required without checked exceptions. Without checked exceptions: - You must check the API docs for every line of code you write to see if it will throw an exception, and if so, what types. - If it throws an exception, you must either add a try/catch block to handle the error appropriately (or wrap it in a new exception type), or you must add documentation to your method to declare that it will bubble up an exception, and of what type. - If new exception types are thrown by underlying code, nothing tells you until your application explodes. With checked exceptions: - The compiler tells you what exceptions code throws, and of what type. - If it throws an exception, you must either add a try/catch block to handle the error appropriately, or declare it in the method prototype. The IDE will do both of these things for you. - If new exception types are thrown by underlying code, the compiler will warn you. > If you're still touting checked exceptions in 2013, you are part of the problem. Stop it. Java needs to evolve, and your fresh-from-1995 opinion is not helping. Stop advocating broken API design and ignorance of API invariants.