Besides, IDEs like eclipse make it very easy to catch exceptions. It would be pure lazyness not to use them. You shouldn't overuse them of course. It's sometimes tempting to use them for conditional logic but you shouldn't do that imho.Often in J2EE environments you work with stuff that can fail for all sorts of reasons. For example your database connection pool may run out of connections because the driver you use has a bug, a sysadmin may inadvertedly shutdown a webservice, an overzealously configured mailserver may reject your javax.mail composed messages, etc. You need to be able to recover from this sort of things because they can and will happen.
Again, you guys seems to think - or sound as if you think - that "checked" exceptions are the only exceptions that are caught and handled. That is a totally wrong premise, although, I agree that RT exceptions do get overlooked by developers often. But that's the developer's fault, and the presense of checked exceptions doesn't really save the situation.
1. The fact that the IDE forces you to handle or re-throw the checked exception before you have compiled your code is certainly very convenient. It is still up to you to _handle_ your errors PROPERLY. Practically on every project I have seen so far, developers would tend to treat exceptions as an afterthought, which eventually would lead to major problems and confusion. For example, the same exception gets caught, logged and re-thrown many times, which results in bloated and confusing log files. Or, an interface defines methods that throw generic (therefore, useless) checked exceptions - because there is no way of knowing what specific exceptions will be thrown by the implementations. The implementations throw specific checked exceptions that immediately get abstracted by the generic super-class. If you are lucky, your client doesn't care to distinguish the specific types and handles all caught checked exceptions the same way. (Then, why do you need those exceptions to be "checked"? Just so that the compiler tells you that SOMETHING may go wrong during the call to the given service? D'uh! Shouldn't you assume that in the first place and catch all errors, not just the checked ones - wherever it is most appropriate per your design - instead of unnecessarily polluting the code and method signatures all along the call chain?) If, in fact, the client is designed to take an alternative course of action depending on the type of the error, then, by all means, the specific checked exception may be useful. But if the client receives a _generic_ checked exception (superclass) that abstracts all sorts of more specific exceptions, you are forced to implement some stupid mickey-mouse logic on the client that would check for "instanceof", or, even worse, some "exception type" attribute on that exception class that will tell you what kind of exception you are dealing with. That completely defeats the purpose of checked exceptions because, at this point, it is you, not the compiler, who does the checking... very awkwardly and unreliably. I'm sure we all have seen this, it's a very common way to handle checked exceptions, unfortunately, and even experienced programmers sometimes do that.
2. I agree that the term "framework" doesn't very well apply to exception handling. It is more of a combination of good design, best practices, and some framework elements like certain base exception classes, well-implemented logger, etc. This is actually what the article is about. I know many people are afraid to use AOP, but I have found Aspects very useful for harnessing exception handling and logging. We are using AspectJ - very carefully - for example, to enforce and consolidate certain safety nets for error handling, properly reset the session context, unwrap the original RT exceptions from RemoteExceptions in the Spring proxy before propagating the original RT exception to the client, etc. Thanks to Aspects, such things are localized, the code never has to be duplicated, and most developers don't even have to ever worry about them.(I must admit, the trade-off for me was that I had to give up my favorite IDE - IntelliJ - in favor of Eclipse b/c IntelliJ does not support AspectJ the way Eclipse does.)
3. I'll say it again: all errors must be handled, and nothing in the programming language should mislead the developer. It's an unfortunate fact that Java developers often rely on the compiler to tell them where they have to catch an exception and which one to catch - and therefore disregard the REAL error handling alltogether. This is so common that Nikita states - without a shred of a doubt - that RT exceptions are certain to slip through the cracks and cause your app to blow... And he is correct, unless the developer approaches error handling as a critical part of the application design, not an afterthought. Other languages do not have checked exceptions, and I have not heard of any language since Java that actually went to implement checked exceptions. C# supposedly was developed to take the best from C++ and Java. Well, they passed on checked exceptions... Same with SmallTalk, Python, etc. Spring, Toplink, Hybernate, etc. - none of them uses checked exceptins...
4. Any environment/system errors are truly unrecoverable errors - in the sense that your application cannot fix them. The application should, of course, gracefully react to them instead of blowing up in the user's face, but it will likely have to handle all such errors in the same generic way. If that's the case, the application will have no use of knowing what particular kind of SQL error has actually occured, or whether the file IO error happened. The error/context info plus the full stack trace should be logged for the administrator/developers to look at, and the user should be presented with a polite message. Therefore, it will only make sense to make such exceptions run-time and, indeed, CATCH and handle all of them where it is most appropriate according to the application design. True, such conditions may be presented as checked exceptions on a deeper level, where the service might want to re-try the operation several times based on the given exception. After all attempts fail, the service should still throw a RT exception to its caller.
That said, I must admit that I have used checked exceptions for years myself, trying to figure out how to solve the "problems with exception handling" that every project manager I've known complained about. I am totally convinced today that, generally, Java checked exceptions bring very little value while provoking countless problems and unnecessary code complexity.