> 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. 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? 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 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.) /LS
