Checked versus Unchecked Exceptions


Checked versus Unchecked Exceptions


There is a religious debate on checked or unchecked exception. Some programmers prefer checked exception, while others prefer the other.

In a nutshell, they have their own prons and crons, we need understand in which case one is more appropriate, and choose the one that best fits current situation.

There are three kinds of throwables in java checked exceptions, runtime exceptions, and errors.

1.         A checked exception is any subclass of Exception (or Exception itself), excluding class RuntimeException and its subclasses. Unchecked exceptions are RuntimeException and any of its subclasses. Class Error and its subclasses also are unchecked.
2.         A Checked exception must be explicitly caught or propagated (rethrown). An unchecked exceptions does not have this requirement. It doesn't have to be caught or declared thrown.
Effective Java
Use checked exceptions for conditions from which the caller can reasonably be expected to recover.
Use runtime exceptions to indicate programming errors.
Errors are reserved for use by the JVM to indicate resource deficiencies, invariant failures, or other conditions that make it impossible to continue execution. It’s best not to implement any new Error subclasses.

Checked Exceptions
Pros of Checked Exceptions:
Compiler enforced catching or propagation of checked exceptions make it harder to forget handling that exception.
Crons of Checked Exceptions:
Versioning: Checked exceptions thrown become part of a method interface and makes it harder to add or remove exceptions from the method in later versions.
Unchecked Exceptions
Pros of Unchecked Exceptions:
1.         Unchecked exceptions do not clutter the code with unnecessary try-catch blocks.
2.         Unchecked exceptions do not clutter the method declarations with aggregated exception declarations.
3.         Unchecked exceptions avoids versioning problems altogether.
Crons of Unchecked Exceptions:
Unchecked exceptions make it easier to forget handling errors since the compiler doesn't force the developer to catch or propagate exceptions
Fixes:
This can be fixed by following good programming practice to document all checked and unchecked exception in Javadoc.



When design a method signature, we should only throw appropriate exception by translating exception to a specific checked (or unchecked) exception. This can avoid proliferation of exception.

Resources:
What are the pros and cons of checked exception?
Effective Java (2nd Edition)
Why doesn't C# have exception specifications?
The Trouble with Checked Exceptions
http://download.oracle.com/javase/tutorial/essential/exceptions/index.html

Labels

adsense (5) Algorithm (69) Algorithm Series (35) Android (7) ANT (6) bat (8) Big Data (7) Blogger (14) Bugs (6) Cache (5) Chrome (19) Code Example (29) Code Quality (7) Coding Skills (5) Database (7) Debug (16) Design (5) Dev Tips (63) Eclipse (32) Git (5) Google (33) Guava (7) How to (9) Http Client (8) IDE (7) Interview (88) J2EE (13) J2SE (49) Java (186) JavaScript (27) JSON (7) Learning code (9) Lesson Learned (6) Linux (26) Lucene-Solr (112) Mac (10) Maven (8) Network (9) Nutch2 (18) Performance (9) PowerShell (11) Problem Solving (11) Programmer Skills (6) regex (5) Scala (6) Security (9) Soft Skills (38) Spring (22) System Design (11) Testing (7) Text Mining (14) Tips (17) Tools (24) Troubleshooting (29) UIMA (9) Web Development (19) Windows (21) xml (5)