Most of the advice on the use of exceptions in the Java language suggests that checked exceptions should be preferred in any case where an exception conceivably might be caught.Recently, several prominent writers have started to come to the position that unchecked exceptions may have more of a place in good Java class design than previously thought. This article looks at the pros and cons of using unchecked exceptions.
Should Java Class exceptions always be checked?
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
My experience is that experienced developers would manage
this stuff in intelligent ways suggested even without such advice.
Inexperienced developers (e.g. undergrads) may have some
bad habits validated by this article …. other than that it gives
some useful scutiny to tradeoffs that all Java developers handle
daily.
For those of you wanting a strategy on exception handling. Normally it naturally fits at the various high level components in your systems architecture. One natural place is above the data access layer, another the business layer. As well, most of the time you intercept the exception and simply log it to a database or file.
Are you advocating unchecked exceptions then? Because it seems that with your advice, you would end up re-throwing an exception anyway to be handled at a higher layer.
… experienced developers would manage this stuff in intelligent ways suggested even without such advice.
Unfortunately, all developers aren’t experienced and a few are definitely not intelligent. Earlier today I saw the following clasic mistake in the code of one of my coworkers:
try {
this.is(someCode);
} catch {}
yepp, The Dreaded Empty Catch Block(tm). Debug *that* in a million-lines project…
I’m not saying excptions are a bad idea and I’m definitely not in favor of the “all exceptions should be unchecked” idea. They are just hard to get right…
What worries me: If exception checking and handling is too cumbersome and complex for the typical Java programmer, that same programmer has no chance whatsoever of understanding and cogently implementing J2EE.
There may need to be some serious reassessment of the expectations of a competent Java programmer if the concept of throwing, trying and catching is mentally evasive.
If you want to handle exceptions, you will. Forcing people to do so only results in lazy programmers rethrowing exceptions and hurting performance.
some advices as I was before lost with exception handling:
– never throw a java exceptions: I mean having a java:io exception popping up in million of lines is a nonsense -> throw your own with a comprehensible name: missingKeyInProperties() or
notInitialized extends frameworkException extends exception
– create a hierarchy tree of exceptions and use polymorphism
(easier for a failure handler, undestanding stacktrace)for ex:
– ApplicationException
– InfrastructureException extends ApplicationException
– UDDIException extends InfrastructureException
– InvalidContentException extends UDDIException
– ServerUnreachable extends InfrastructureException
so it is a lot easier and not a problem to add a new set of exceptions in tree
– I use both checked and normal exception, depends where
Martin Fawler (thinking in java) has written a good articles here (how to implement them, why, when)
http://www.mindview.net/Etc/Discussions/CheckedExceptions
– I always try to save or give info to operative people, a comprehensible exception and possible cause in logs, and use nothing else than log4j (date formatting classname help a lot)
I have somewehere a very good document, will post link tomorrow
oups read bruce eckel already list in articles, Martin Fawler is for refactoring 😉
> If you want to handle exceptions, you will. Forcing people
> to do so only results in lazy programmers rethrowing
> exceptions and hurting performance.
You’re 1/2 correct. C# is great in that it allows you to ignore exceptions. It goes with C#’s theory of letting the development team make the rules instead of force-feeding some language designer’s ideology on everyone. Unhandled excpetions are fantastic for rapid prototyping as well as for allowing a class implementation to be separate from exception handling. If a Java class throws an exception, that is permanently part of the published API and you’ll always be stuck with it. That part of your post you are correct about – forcing checked exceptions leads to empty catch blocks.
However, I think your conclusion that forcing checked exceptions causes developers to hurt performance is bogus. Exception handling should have little to do with performance because, as stated by Joshua Bloch’s Item #39 in Effective Java, exceptions should only be used for exceptional conditions. If exceptions are thrown all the time, then yes you’ll have performance problems, but if that’s the case then there is something entirely messed up with the programmer who writes code that way. If performance is a concern with exceptions, then you’re not using exceptions correctly.
However, I think your conclusion that forcing checked exceptions causes developers to hurt performance is bogus. Exception handling should have little to do with performance because, as stated by Joshua Bloch’s Item #39 in Effective Java, exceptions should only be used for exceptional conditions.
Matt, are you aware of how exception-handling really works underneath the covers? Essentially, what it does is establish a stack frame — nested stack frames are often connected in a linked list — and thus, regardless of whether an exception is thrown or not, you still incur the overhead of setting up the exception stack frame. Even if you never throw the exception. While, in general, I like exception handling as a form of robust programming, the concept is anathema in performance-intensive computing.
“try {
this.is(someCode);
} catch {}”
I don’t believe it. The least you could do is to output the exception.Besides,you should always pass to catch what exception you want to handle. I have never seen empty catch blocks in my whole programming life.Seriously.
The way I see it, the problem with checked exceptions is, that they are part of the method signature, so you can’t change the exceptions without potentially breaking other code.
The problem with unchecked exceptions is, is that they aren’t part of the signature, so you don’t know what exceptions are thrown by a method. So you would have to properly document what exceptions can be thrown, but we all know how well code is documented most of the time…
I have never seen empty catch blocks in my whole programming life.
Consider yourself lucky!
You don’t have any idea what a stack frame is, do you? All programming languages (at least that I know of) creates a new stack frame each time a method/function is called. That’s the way it keeps track of the function’s local variables, and where to return to when it finishes. Because the stack frames is right there on the stack, all that needs to be done is to iterate trough them when an exception is thrown. When you don’t throw an exception, there is absolutely no overhead.
I just created a small benchmark to test this. As far as I can see, there is absolutely no difference between a loop doing virtually nothing, and the same loop pluss a try/catch (inside the loop). I can post the entire test if you like, it’s less than 20 lines.
– All exceptions should be caught and handled immediately if possible, not just logged!
– or THROWN back to the caller. Period.
Anything else and your a lazy hack ( or Microsoft programmer ).
Java teachers, including Eckel, have IGNORED the THROWS clause and have not properly handled exceptions because of this oversite.
All exceptions are important in enterprise programming and None can be ignored.
public Object pop()
throws FileNotFoundException
{
}
Learn to THROW your exceptions back to your caller!
Until you learn that you don’t know what your doing with Exceptions. I’d say that a good 80% of all exceptions should be thrown back to the caller, depending upon how well you factor your classes….