Did you read the entire article… I thought it was rather useful insight, particularly at the end. If you already knew all of this, did you not realize that before reading the entire thing?
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.
You can invoke GC (which generally speaking, you should not), but this doesn’t guarantee it will clean up anything. OOM exceptions should be considered terminal, as they are an Error, not an Exception.
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.
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.
> 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.
“This post is clearly written by someone who is new to Java”
That was uncalled for. But, since you’ve decided to immediately call into question people’s credentials, let me start with mine. I’ve done a little over 30 years of software development, and in that time I’ve programmed in no less than three assembly languages, several BASICs, Pascal, C, C++, JavaScript, dabbled with C#, dabbled with Go, dabbled with Python, been subjected to some Perl and PHP, etc. I’m not God’s Gift to Software Development, but I think I have enough experience that my opinion on this matter shouldn’t be discarded as uninformed.
“and starts with the antique assumption that the runtime/checked exception dichotomy is a good idea.”
I hope you’re aware that you’re begging the question. In any case, I think checked exceptions are fantastic.
1. The “burden” of dealing with them is minuscule, especially when using modern IDEs. It takes just a few clicks or key presses to add try/catch blocks or re-throw exceptions as necessary. You don’t even have to waste time looking up documentation (which may be wrong or even nonexistent). Your tool-chain (IDE and compiler) handles the mundane details for you.
2. It forces developers, who are often hurried, and who often make mistakes, to think about things that could go wrong, and deal with them (one way or another). Oh, sure, you see plenty of “catch (Exception e)” style abuses, but that particular “code smell” is so strong (i.e., easily identified) that it can make code reviews (personal and public) easier. Code reviews in languages with only unchecked exceptions are much more difficult and time consuming.
3. Checked exceptions speeds development. Much less time is spent reading and re-reading API documentation to make sure you’ve caught all the possible exceptions that might be thrown (so that you can do things like produce meaningful error messages or log entries based on the exception thrown).
4. Unchecked exceptions are a production run-time nightmare. My anecdotal but extensive experience is that languages with only unchecked exceptions cause far too many costly (in both time and money) production headaches. Never, ever defer until run-time, errors that can be caught at compile-time! Admittedly, it could be that my application domain colors my opinion here (I work on large systems, not small systems).
The best argument I’ve heard against checked exceptions is that they “bloat the code”. It’s true: checked exceptions requires more code. But I’m writing code, not poetry. My job is to get the implementation right (which checked exceptions help me do) and to write reliable and robust software. Developers who put more emphasis on writing pretty code (sorry, “highly expressive”) might want to consider becoming artists instead, where they can fashion “pretty” creations to their heart’s content.
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.
Not to mention it is slow as hell. I can only imagine the pain the author had to go through to write a java program for handling “10,000 transactions per seconds”!
>> Not to mention it is slow as hell.
Not necessarily. In most cases, the code can be optimized by the compiler to be on par with C/C++ code or even faster. The “stop-the-world” garbage collectors do cause slight performance trade-offs, but coming from a C++ background, I would much rather have automatic garbage collection than code reviewing and code reviewing to discover and eliminate all memory leakages. While processors are not doubling their speeds every 18 months, computers are still getting faster and faster. Even if your argument was true, I’m willing to take a slight performance hit over flexibility.
>> pain the author had to go through to write a java program for handling “10,000 transactions per seconds”!
Useless and ambiguous argument. Which stage of the software development are you referring to: architecting, coding, production? I find architecting and writing Java is fun. Not to mention the plethora of well tested libraries and frameworks which ship with JDK make my life easier.
Thanks for posting.
“Java is flawed by design. I feel sorry for people who are still using it. There are much better alternatives like .NET. Not to mention it is slow as hell.”
Obvious troll is obvious!
Grant you are a retarded loser. It’s .NET that’s flawed. Still clinging to exes, dlls and com components. LOL like it’s 1990.
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.
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.
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.
Runtime exceptions can turn into ugly production problems. I prefer a combination of Validation, Success/Failure, Some/None and checked exceptions.
Runtime exceptions can turn into ugly production problems. I prefer a combination of Validation, Success/Failure, Some/None and checked exceptions.
“ugly production problems”?
If you are talking about performance, the only real cost of exceptions is that of creating the stack trace. If the exception is never thrown, there is virtually no overhead or associated costs of try and catch. http://apmblog.compuware.com/2011/04/12/the-cost-of-an-exception/
Before reading full article, I thought another blah-blah but after reading it I can say, it does offer some insight. In real world there are many situation,when you want to catch RuntimeException.
[…] said Operations Manager. Rob rushed back to the office and discovered that an uncaught run-time exception on a rare malformed request had brought the system down. The system was single point of failure. […]
It was looking for an article explaining the principle of exception handling in Java and the differences between checked and unchecked exception. This is the perfect match!
For the very first time, I reblog something on WordPress.com 🙂
10K-LOC 
[…] Comments …read more […]
What did I just waste my time on?
Did you read the entire article… I thought it was rather useful insight, particularly at the end. If you already knew all of this, did you not realize that before reading the entire thing?
Good post. OutOfMemory is another RuntimeEcxeption that should be caught in high availability applications invoking garbage collector for clean up.
Actually “OutOfMemory” is an ERROR, not a RuntimeException.
Source: http://docs.oracle.com/javase/7/docs/api/java/lang/OutOfMemoryError.html
Calling the Garbage Collector on the JVM does not in any way, shape, or form make it collect garbage.
And that’s just one example amongst thousands of others 😦
javax.xml.ws.WebServiceException is also quite commonly annoying.
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.
You can invoke GC (which generally speaking, you should not), but this doesn’t guarantee it will clean up anything. OOM exceptions should be considered terminal, as they are an Error, not an Exception.
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.
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.
> 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.
“This post is clearly written by someone who is new to Java”
That was uncalled for. But, since you’ve decided to immediately call into question people’s credentials, let me start with mine. I’ve done a little over 30 years of software development, and in that time I’ve programmed in no less than three assembly languages, several BASICs, Pascal, C, C++, JavaScript, dabbled with C#, dabbled with Go, dabbled with Python, been subjected to some Perl and PHP, etc. I’m not God’s Gift to Software Development, but I think I have enough experience that my opinion on this matter shouldn’t be discarded as uninformed.
“and starts with the antique assumption that the runtime/checked exception dichotomy is a good idea.”
I hope you’re aware that you’re begging the question. In any case, I think checked exceptions are fantastic.
1. The “burden” of dealing with them is minuscule, especially when using modern IDEs. It takes just a few clicks or key presses to add try/catch blocks or re-throw exceptions as necessary. You don’t even have to waste time looking up documentation (which may be wrong or even nonexistent). Your tool-chain (IDE and compiler) handles the mundane details for you.
2. It forces developers, who are often hurried, and who often make mistakes, to think about things that could go wrong, and deal with them (one way or another). Oh, sure, you see plenty of “catch (Exception e)” style abuses, but that particular “code smell” is so strong (i.e., easily identified) that it can make code reviews (personal and public) easier. Code reviews in languages with only unchecked exceptions are much more difficult and time consuming.
3. Checked exceptions speeds development. Much less time is spent reading and re-reading API documentation to make sure you’ve caught all the possible exceptions that might be thrown (so that you can do things like produce meaningful error messages or log entries based on the exception thrown).
4. Unchecked exceptions are a production run-time nightmare. My anecdotal but extensive experience is that languages with only unchecked exceptions cause far too many costly (in both time and money) production headaches. Never, ever defer until run-time, errors that can be caught at compile-time! Admittedly, it could be that my application domain colors my opinion here (I work on large systems, not small systems).
The best argument I’ve heard against checked exceptions is that they “bloat the code”. It’s true: checked exceptions requires more code. But I’m writing code, not poetry. My job is to get the implementation right (which checked exceptions help me do) and to write reliable and robust software. Developers who put more emphasis on writing pretty code (sorry, “highly expressive”) might want to consider becoming artists instead, where they can fashion “pretty” creations to their heart’s content.
i want my 12 volts!!
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.
Java is flawed by design. I feel sorry for people who are still using it. There are much better alternatives like .NET.
Not to mention it is slow as hell. I can only imagine the pain the author had to go through to write a java program for handling “10,000 transactions per seconds”!
>> Not to mention it is slow as hell.
Not necessarily. In most cases, the code can be optimized by the compiler to be on par with C/C++ code or even faster. The “stop-the-world” garbage collectors do cause slight performance trade-offs, but coming from a C++ background, I would much rather have automatic garbage collection than code reviewing and code reviewing to discover and eliminate all memory leakages. While processors are not doubling their speeds every 18 months, computers are still getting faster and faster. Even if your argument was true, I’m willing to take a slight performance hit over flexibility.
>> pain the author had to go through to write a java program for handling “10,000 transactions per seconds”!
Useless and ambiguous argument. Which stage of the software development are you referring to: architecting, coding, production? I find architecting and writing Java is fun. Not to mention the plethora of well tested libraries and frameworks which ship with JDK make my life easier.
Thanks for posting.
“Java is flawed by design. I feel sorry for people who are still using it. There are much better alternatives like .NET. Not to mention it is slow as hell.”
Obvious troll is obvious!
Grant you are a retarded loser. It’s .NET that’s flawed. Still clinging to exes, dlls and com components. LOL like it’s 1990.
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.
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.
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.
Runtime exceptions can turn into ugly production problems. I prefer a combination of Validation, Success/Failure, Some/None and checked exceptions.
Runtime exceptions can turn into ugly production problems. I prefer a combination of Validation, Success/Failure, Some/None and checked exceptions.
“ugly production problems”?
If you are talking about performance, the only real cost of exceptions is that of creating the stack trace. If the exception is never thrown, there is virtually no overhead or associated costs of try and catch.
http://apmblog.compuware.com/2011/04/12/the-cost-of-an-exception/
Good Post
Before reading full article, I thought another blah-blah but after reading it I can say, it does offer some insight. In real world there are many situation,when you want to catch RuntimeException.
[…] said Operations Manager. Rob rushed back to the office and discovered that an uncaught run-time exception on a rare malformed request had brought the system down. The system was single point of failure. […]
It was looking for an article explaining the principle of exception handling in Java and the differences between checked and unchecked exception. This is the perfect match!
For the very first time, I reblog something on WordPress.com 🙂
Hi Pierre:
I’m glad you enjoyed. Thanks for the reblog.
Regards,
Umer