Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I am confused as to when the custom exception should extend RunTimeException and when it has to extend Exception . Could you please explain me is there any disadvantage of extending RunTimeException directly?

Thanks!

RuntimeException are unchecked while Exception are checked (calling code must handle them).

The custom exception should extends RuntimeException if you want to make it unchecked else extend it with Exception .

With unchecked exceptions calling code method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught.

As the calling method may not handle `RuntimeException``, one needs to be careful while throwing RuntimeException .

Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way. Such problems include arithmetic exceptions, such as dividing by zero; pointer exceptions, such as trying to access an object through a null reference; and indexing exceptions, such as attempting to access an array element through an index that is too large or too small.

Runtime exceptions can occur anywhere in a program, and in a typical one they can be very numerous. Having to add runtime exceptions in every method declaration would reduce a program's clarity. Thus, the compiler does not require that you catch or specify runtime exceptions (although you can).

Source/Further Reading: Unchecked Exceptions - The Controversy

If you extend RuntimeException , you don't need to declare it in the throws clause (i.e. it's an unchecked exception). If you extend Exception, you do (it's a checked exception).

Some people argue that all exceptions should extend from RuntimeException , but if you want to force the user to handle the exception, you should extend Exception instead.

One case where it is common practice to throw a RuntimeException is when the user calls a method incorrectly. For example, a method can check if one of its arguments is incorrectly null. If an argument is null, the method might throw a NullPointerException, which is an unchecked exception.

Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw.

Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

for more read this.

RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine.

RuntimeException and its subclasses are unchecked exceptions. Unchecked exceptions do not need to be declared in a method or constructor's throws clause if they can be thrown by the execution of the method or constructor and propagate outside the method or constructor boundary.

If you extend Exception , you need to catch where ever you throw your ValidationException .

If you are in an application framework and your framework is good to handle the exception when there is an exception notification from your code. In that case you can use your custom exception class as subclass of RuntimeException.

This will help you from NOT to write the code to handle the exception through out the exception hierarchy.

Thanks for contributing an answer to Stack Overflow!

• Please be sure to answer the question . Provide details and share your research!

But avoid …

• Asking for help, clarification, or responding to other answers.
• Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers .