Differences between Runtime/Checked/Unchecked/Error/Exception

21,162

Solution 1

Throwable is at the top off all exceptions. Underneath Throwable you have Error and Exception. Underneath Exception you have RuntimeException.

Java has two types of exceptions - checked and unchecked. Checked exceptions are enforced by the compiler (you have to declare them in the throws clause and catch them eventually). Unchecked exceptions are not enforced for catching or declaring in throws clause.

(Controversial part of the answer)

Throwable exists so that there is a parent for all exception types. You should never declare that you throw Throwable and never catch it (unless you really really really know what you are doing).

Error exists to indicate issues with the runtime environment, things that your program probably cannot recover from, such as a badly formatted class file or the VM running out of memory. You should not catch an Error unless you really know what you are doing.

Exception exists as the root for all non-programmer errors (see RuntimeException for the "exception" to this) , such as a file cannot be created because the disk is full. You should not throw, throws, or catch Exception. If you have to catch Exception make sure you know what you are doing.

RuntimeException exists to indicate all programmer error, such as going past the end of an array or calling a method on a null object. These are things that you should fix so that they do not throw exceptions - the indicate that you, the programmer, screwed up the code. Again, you should not catch these unless you know what you are doing.

Solution 2

Since I am a new Java developer, I have also faced some difficulties for distinguishing and dealing with different types of exceptions. That is why I have made a short note on this topic, and whenever I get confused I go through it. Here it is with the image of the Throwable class hierarchy:
Throwable Class Hierarchy

[image courtesy of JavaTpoint].

There are three key classes to remember here: Throwable, Exception and Error. Among these classes Exception can be divided into two types: "Checked Exception" and "Unchecked Exception".

Checked Exception:

  • These are the classes that extend Throwable except RuntimeException and Error.
  • They are also known as compile time exceptions because they are checked at compile time, meaning the compiler forces us to either handle them with try/catch or indicate in the function signature that it throws them and forcing us to deal with them in the caller.
  • They are programmatically recoverable problems which are caused by unexpected conditions outside the control of the code (e.g. database down, file I/O error, wrong input, etc).
  • Example: IOException, SQLException, etc.

Unchecked Exception:

  • The classes that extend RuntimeException are known as unchecked exceptions.
  • Unchecked exceptions are not checked at compile-time, but rather at runtime, hence the name.
  • They are also programmatically recoverable problems but unlike checked exception they are caused by faults in code flow or configuration.
  • Example: ArithmeticException,NullPointerException, ArrayIndexOutOfBoundsException, etc.
  • Since they are programming errors, they can be avoided by nicely/wisely coding. For example "dividing by zero" produces an ArithmeticException, which can be avoided by a simple check on the divisor. Similarly we can avoid NullPointerException by simply checking the references: if (object != null) or even using better techniques.

Error:

  • Error refers to an irrecoverable situation that is not being handled by a try/catch.
  • Example: OutOfMemoryError, VirtualMachineError, AssertionError, etc.

Why are these many types?

In addition to Stephen C's answer I want to say: exception handling is a relatively expensive operation in Java. We should not put all exceptional situation in a try/catch block. Excessive use of try/catchs may hamper program performance.

In conclusion, Exceptions should be handled programmatically whenever possible. On the other hand, we cannot handle Errors, so these might be some logical reasons why there are many types of exceptions.

Solution 3

TofuBeer's answer explains clearly what the exception classes mean.

Why these many types? Instead Java may simply follow a simple design(just try/catch all types) to handle an abnormal condition in a program?

Why? Because they are necessary! Without those 4 classes, handling exceptions by broad category would be impractical.

  • How would you catch "all fatal JVM errors" without the Error class?
  • How would you catch "all exceptions that are not JVM fatal errors" without the Exception class?
  • How would you catch "all unchecked exceptions" without the RuntimeException class?

Solution 4

  • Error (throws by VM, should not be caught or handled)
    1. VM Error
    2. Assertion Error
    3. Linkage Error ...so on
  • Runtime/Uncheck Exception(programming error, should not be caught or handled)
    1. NullPointerException
    2. ArrayIndexOutOfBoundException
    3. IllegalArgumentException ... so on
  • Check Exception(Anything Else, Applications are expected to be caught or handled)
    1. IOException
    2. FileNotFoundException
    3. SQLException ...so on
Share:
21,162

Related videos on Youtube

JavaUser
Author by

JavaUser

Updated on January 04, 2020

Comments

  • JavaUser
    JavaUser over 4 years

    What are the Runtime exceptions and what are Checked/Unchecked Exceptions and difference between Error/Exception.Why these many types? Instead Java may simply follow a simple design(just try/catch all types) to handle an abnormal condition in a program?

  • Bombe
    Bombe about 13 years
    Yeah, as if not catching an exception and just letting it kill the thread is an acceptable solution.
  • Admin
    Admin about 9 years
    It usually considered a Bad Idea® to generate your own RuntimeException's. Do so with care, and not just as a shortcut.
  • Qw3ry
    Qw3ry over 6 years
    +1 for the nice picture. Sidenote: it's not strictly correct that an Error is not catchable. No one prevents you from writing try { sometching(); } catch(Error e) { }, but it's actually a bad idea to do this (see @TofuBeer's answer for details).