Hi Pradeep,
I'd tend to agree with Alex... the choice of checked vs. unchecked exceptions tends to be governed by the underlying assumptions upon which an API or framework is built. Depending on how rigorously and consistently those assumptions are enforced, it may be acceptable to rely entirely on unchecked exceptions, on checked exceptions, or on a mix of the two.
The rationale behind the checked exception is to communicate to a developer that there is a well-known error condition in an API call. Furthermore, I'd say that such an exception is most appropriate when it represents an error that the developer
is aware ofcan do something abouthas a choice for how to address the problem (usually)could cause broader code failures if left unaddressed (often) If these conditions are met, it seems reasonable to formally communicate the need to address the error. This would be particularly true (as Alex observed) when working between code layers, especially if the layers wwere independently developed and did NOT have a formal handling infrastructure in place.
Unchecked exceptions, on the other hand, are useful in cases where the IS such an infrastructure in place to provide an acceptable "safety net" should such an error occur. They also tend to be useful when there are error conditions that have a suitable default recovery action that can be enforced in code should the developer elect to ignore the fault. I personally tend to think that one of the reasons unchecked exceptions are so popular today is due to the more sophisticated enterprise frameworks that have evolved over the lasst few years. If such frameworks are consistent and reasonable in how they handle such error conditions, they can offer a major boon to developers.
The situations where the development community tends to get itself into trouble is when it uses handling alternatives as a reflex action, decoupled from thought and planning. There is a risk that developers will simply ignore unchecked exxceptions because they don't have to do anything about them. Likewise, there's a risk that developers will opt for the easy solution of a checked exception by "hiding" the source of the error in an empty catch block. Both stem from what I like to call reflex coding; both tend to substantially decrease code maintainability.
Hope this helps; thanks very much for your question. On a totally unrelated
thread, thanks for letting me put the table of contents for "Robust Java" on your blog, Alex.
Best wishes,
Steve