How to identify checked and unchecked exceptions in java?

Question

While reading about exception, I will always come across checked exceptions and unchecked exceptions, So wanted to know how to distinguish that which is what?

Edit: I want to know if i create any exception class then how can i create as a checked or as an unchecked?

and what is the significance of each?

Solution 1

All Throwables except subclasses of java.lang.RuntimeException or java.lang.Error are checked. Properly, in Java, "exceptions" are subclasses of java.lang.Exception, "errors" are subclasses of java.lang.Error and java.lang.Throwable is not usually subclassed directly.

Programs are not supposed to create their own Error subclasses (though the documentation is rather ambiguous on that) so generally you always create Exceptions, using a RuntimeException if you don't want it to be checked.

To know at run-time if you have a checked exception you could use:

if(throwable instanceof Exception && !(throwable instanceof RuntimeException)) {
    // this is a checked Exception
    }

A checked exception is one which must be either handled in a catch clause, or declared as being thrown in the method signature; the compiler enforces this. Generally, one uses checked exceptions for exceptions which should be handled by the calling code, while unchecked exceptions are for conditions which are the result of a programming error and should be fixed by correcting the code.

That said there is much debate in the Java community about the efficacy of using checked exceptions vs. unchecked exceptions everywhere - a subject way to deep to discuss in this answer.

EDIT 2012-10-23: In response to comments (which are quite valid), to clarify, the following would be what is required to determine if a captured Throwable is a checked Throwable as opposed to a checked Exception:

if(obj instanceof Throwable && !(obj instanceof RuntimeException) && !(obj instanceof Error)) {
    // this is a checked Throwable - i.e. Throwable, but not RuntimeException or Error
    }

If the object in question is known to be an instance of Throwable (e.g. it was caught), only the second part of the above 'if' is needed (e.g. testing for Throwable is redundant).

Solution 2

See the Java Language Spec, chapter 11:

The unchecked exceptions classes are the class RuntimeException and its subclasses, and the class Error and its subclasses. All other exception classes are checked exception classes. The Java API defines a number of exception classes, both checked and unchecked. Additional exception classes, both checked and unchecked, may be declared by programmers.

You could check this via instanceof at runtime, though I don't really see where this would be useful.

As to the second part of your question:

• checked exception represent expected error conditions, which can occur during normal program execution and therefore always have to be handled programatically (which the compiler enforces)

• unchecked exception represent unexpected error conditions and signify an abnormal state of your program, due to invalid input, bugs or runtime restrictions (eg memory); the compiler won't force the programmer to handle these, ie you only have to care for them if you know of their occurrence

Solution 3

• Error is internal VM error and usually you can not manage it.
• Exception - you are able to catch and handle it

Checked vs Unchecked

• checked exception is checked by the compiler and as a programmer you have to handle it using try-catch-finally, throws
• unchecked exception is not checked by the compiler but you optionally can manage it explicitly

IntelliJ IDEA's Type Hierarchy tool is useful when you want to find more

Solution 4

If the exception class is a subclass of RuntimeException, it's not checked and does not have to be declared for functions or caught, etc. Error exceptions also do not have to be declared/caught. Is that what you're asking?

View more solutions

Comments

[Michael Borgwardt]

Errors are also unchecked, though I guess you could argue that they're not exceptions...

[SyntaxT3rr0r]

@Christoph: and of course there's a whole school of programming that consider that "an expected error condition" is not really an error and that seen that a lot of languages do perfectly fine without even the concept of checked exception their existence is debatable. Joshua Bloch, Effective Java, "Prefer state testing method over exception". And then of course there's the school of programming that hates GOTOs and considered using checked exceptions for flow control to be spaghetti-like GOTO programming. I'm not siding with one camp or another, just stating the current state of affair :)

[BeeOnRope]

This misses exceptions which inherit from Throwable but not from Exception, which are checked. Generally you have: An unchecked 'exception' t will satisfy: t instanceof Error || t instanceof Exception Everything else which is instanceof Throwable is checked. An error is a type of Exception in the general sense.

[Lawrence Dol]

@Bee: In one sense that's quite correct; but, Errors are Errors, not Exceptions, and Java makes the distinction in naming (Error handling is another case where theory fails in practice, but, I thought, a related yet separate discussion). That is, Errors are also checked, but in Java nomenclature they are errors, not exceptions; However both errors and exceptions are Throwables. According to Java, an Error is a Throwable but not an Exception (more generally in English, Errors are "exceptions", but they are not "Exceptions").

[BeeOnRope]

Exactly. That said, I'd assume a method which decided whether a throwable was a checked or not would return true for all checked exceptions, not just checked Exceptions. That is, it would take the little e sense of the word. I can't see a valid use case for excluding things which extend Throwable but not Exception or Error. What do you call those anyway?

[Lawrence Dol]

@Bee: I don't call them anything; I've never encountered someone using a direct subclass of Throwable. BTW I have updated my answer to assuage your concern.

[BeeOnRope]

Looks good. Often the check itself for instanceof Throwable can be itself omitted because if you caught something, it must be a Throwable. Similarly for Exception if you caught Exception (or a subclass), etc.

[Lawrence Dol]

@Bee: Yes, that's what I meant by my last paragraph.

[Ben]

Could you explain why this might work to improve your answer?