From: Ugo Cei [mailto:[EMAIL PROTECTED]
[1] http://www.mindview.net/Etc/Discussions/CheckedExceptions [2] http://www.artima.com/intv/jdom3.html [3] http://www.artima.com/intv/handcuffs.html [4] http://www.theserverside.com/articles/article.tss?l=RodJohnson Interview (read inside the PDF of the sample chapter) [5] http://www.artima.com/intv/solid.html
Summary of these appear to be that the difference is if your code must handle exceptions gracefully (for example, as Gosling says, avionics), or if it is OK to just drop that web server request.
What this further boils down to is the use of Exceptions for
exceptional circumstances, or as a standard signalling mechanism.
For example, in C# the idea is that a program should never throw any exceptions. If one is thrown, something has gone very very bad. You could say that Exceptions in C# are like Errors in Java.
In Java, Exceptions are a signalling mechanism that is expected to be used during normal execution.
I must say I have conflicting views myself. I agree that exceptions should be for exceptional events. Perfect examples are a file is not found that we expected to find, or we could not open a socket for some reason. We cannot reasonably control these types of resources because the Operating System is in control. Therefore we need to gracefully handle these types of issues. They are not true Errors in the Java sense, because the program can expect to recover from these temporary issues.
Simply throwing a RuntimeException is bad IMO because there is no contextual information to help narrow the search. I have no issues with throwing a specific *type* of RuntimeException like IllegalArgumentException because it at least give some context to the issue.
I am not in favor of using exceptions as a signaling mechanism to control program flow--it is much more verbose than other approaches, not to mention heavy to the runtime performance.
For example, Hejlsberg lists as one bad thing about rethrowing exceptions that you loose the stack trace. But if the Exception is supposed to be handled, then who cares about the stack trace?
If you rethrow the exact same exception, shouldn't the stack trace remain in tact? If you throw a wrapped exception, then you can still get to the original stack trace. The stack trace is important to developers because it helps pinpoint the exact place where the problem occurred.
So - checked exceptions work fine when you can and must handle the circumstances giving rise to them, while unchecked
work fine if you're just expected to let them propagate and
have them written to a log file at the bottom of the stack.
I can absolutely agree with this statement. I must say that when I had to debug a system that only threw one type of exception, the base RuntimeException, it was a bugger (pun and inference intended).
(I still think one should declare known RuntimeExceptions in the throws clause. For example, if I know that the
code will throw an IllegalArgumentException if the first
argumetn is less than zero, I should declare the
IllegalArgumentException.)
:/
As soon as you declare it, the compiler will require a try/catch or throws clause--even if it is a RuntimeException.
I already mentioned where I think checked exceptions make sense (e.g. when accessing resources not under the control of the application). IMO, where they do not make sense is when we are dealing with parsing strings, like the Formatter.parse() method. Many times the string is known ahead of time so when it is correct, there is nothing that will ever be thrown. If an exception is to be thrown at all, it should be a runtime exception.
I wrote a new container (research project for Java 1.5, not intending it for any other project) that really only had one checked exception. It really cleans the code up. The one checked exception was in case the component could not be instantiated. That's it. Everything is fairly easy to understand.
