RuntimeException in Java: Meaning, Examples, and Checked Exceptions

java.lang.RuntimeException is Java’s base class for unchecked exceptions. The compiler does not require a method to catch one or declare it with throws, but a program can catch it when recovery is appropriate. Runtime exceptions often point to a defect in program logic or an assumption that did not hold.

Understanding java.lang.RuntimeException in Java

A runtime exception can occur while a program is running. Common examples include NullPointerException, ArrayIndexOutOfBoundsException, and ArithmeticException. Their names describe different failures:

• A NullPointerException can occur when code dereferences a null reference, such as calling length() on a null string.
• An ArrayIndexOutOfBoundsException can occur when code reads or writes an array position below zero or at least as large as the array’s length. For an array of length five, valid indexes are zero through four.
• An ArithmeticException can occur when integer division uses a divisor of zero. This statement concerns integer division; floating-point division by zero follows different Java rules.

These exceptions are not limited to one kind of cause, and being unchecked does not make them impossible to handle. First look for a way to prevent the bad state: initialize and validate references, calculate indexes from the array length, and check a divisor when zero is not meaningful for the operation. For example, an array index is valid when index >= 0 && index < numbers.length.

Example

This complete example validates each input before use and prints the resulting values.

public class RuntimeExceptionExample {
    public static void main(String[] args) {
        String text = "Java";
        int[] numbers = {10, 20, 30, 40, 50};
        int index = 2;
        int numerator = 12;
        int denominator = 3;

        if (text != null) {
            System.out.println("Text length: " + text.length());
        }

        if (index >= 0 && index < numbers.length) {
            System.out.println("Selected number: " + numbers[index]);
        }

        if (denominator != 0) {
            System.out.println("Quotient: " + numerator / denominator);
        }
    }
}

Text length: 4
Selected number: 30
Quotient: 4

The string is present, the selected index is within the array, and the divisor is nonzero. The null dereference, invalid array index, and zero-divisor cases described here were not executed. If one of those failures occurs, the corresponding runtime exception is thrown. When an exception is not caught, statements after the failing operation in that execution path do not run. To demonstrate each failure, change one input at a time and handle that case separately; do not put several uncaught failures in sequence and expect each one to be reached.

Catching can be useful when the program has a meaningful recovery action, but a broad catch that merely hides a programming defect makes diagnosis harder. Prefer to validate inputs near where they enter the program and fix the cause of unexpected states. Testing and debugging help find such defects; code analysis tools can also flag some risky patterns.

Difference Between java.lang.RuntimeException and java.lang.Exception

java.lang.RuntimeException extends java.lang.Exception, so every runtime exception is also an exception. However, java.lang.Exception also has checked subclasses that do not extend RuntimeException. The practical distinction is the compiler’s handling requirement, not whether the cause is external or whether a developer can catch it.

A checked exception must be caught or declared in the method’s throws clause. For example, code that calls an API declaring a checked exception must account for that exception to compile. For an unchecked exception such as NullPointerException, Java imposes no corresponding catch-or-declare requirement. Both checked and unchecked exceptions can be caught with try and catch; catching a runtime exception is appropriate when the code can take a useful, well-defined recovery action.

Error is a separate branch under Throwable, not a subclass of Exception. This distinction helps explain why the compiler’s checked-exception rules apply to exception types other than RuntimeException subclasses and Error subclasses.

An uncaught exception terminates the thread in which it occurs. If it escapes from the main thread, the application may end; an uncaught exception in another thread does not by itself mean every thread must stop. Handling should match the failure: recover where the program has a sound recovery path, and correct defects that leave the program in an unintended state.

Conclusion

java.lang.RuntimeException is unchecked, so Java does not require it to be caught or declared, even though it can be caught. Null dereferences, invalid array indexes, and integer division by zero are common examples. Validate values and fix the underlying defect when possible; use a catch block when it supports a clear recovery action. Remember that an uncaught exception ends its thread, while the effect on the whole application depends on which thread failed.