1

Why does java.lang.RuntimeException (or sub-class of it) not force us to write code in try/catch

Provided:

java.lang.Exception or sub-class of it (termed as checked-exception) forces us to write code in try/catch block or forces us to handle it.

Then why does java.lang.RuntimeException or sub-class (termed as unchecked-exception) not force us to write code in try/catch block even if it is extending java.lang.Exception

Added Example:

public class ExceptionTest
{
    public static void main(String[] args)
    {
        // HOW COMPILER COME TO KNOW or DECIDE THIS METHOD IS THROWING RuntimeException or Exception (Keep in mind java.lang.RuntimeException is again extending java.lang.Exception) 
        new ExceptionTest().test_1();
    }

    public void test_1() throws MyException
    {

    }
}

class MyRuntimeRuntimeException extends RuntimeException
{
    public MyRuntimeRuntimeException() {
        // TODO Auto-generated constructor stub
    }
}

class MyException extends Exception
{
    public MyException() {
        // TODO Auto-generated constructor stub
    }
}
Rakesh Bhalani
  • 668
  • 4
  • 10

4 Answers4

1

This is part of the design o the Java language. RuntimeExceptions are intended to be Exceptions that represents errors on the behalf of the programmer and are called unchecked exceptions. All other exceptions are checked exceptions and the intent is that programmers should have to handle them explicitly by either catching them or declaring them with a throws declaration on the method call to let callers know they could be thrown.

  • you mean compiler will check whether custom-exception(IOException) is extending RuntimeException or Exception to force try/cath? – Rakesh Bhalani Aug 08 '13 at 07:18
1

This is because the design of the java compiler know that when there is a class which extends RuntimeException at that time it will not force to handle it. Because those exceptions are hardly to occur.

So the compiler it self is designed for checking this scenario.

Mr.k
  • 146
  • 6
0

The definition it selfs is enough clear I think.

Run time exception means that can not be predetermined by the syntax check, and the dry execution of the code, thus the compiler can not be aware of possible error happening at such point in your code.

LMG
  • 966
  • 1
  • 12
  • 28
  • Doesn't answer the question. The compiler can't be aware of I/O errors either, but they aren't `RuntimeExceptions.` – user207421 Aug 08 '13 at 07:18
0

Methods that have the potential to throw some exceptions are so pervasive that if every method that could throw them was required to declare them they would appear in almost all method declarations. For example, any method that uses a reference to access a member of an object, outside a try-block with a catch that covers NullPointerException, has the potential to throw NullPointerException.

Declaring NullPointerException on every method conveys no more information than declaring it on no methods, and would clutter the throws declarations.

The RuntimeException system avoids filling up throws clauses with exceptions that can be thrown everywhere and should rarely be caught.

Patricia Shanahan
  • 25,849
  • 4
  • 38
  • 75
  • i have edited quetion to add example please have a look at it. – Rakesh Bhalani Aug 08 '13 at 07:41
  • @RakeshBhalani The declaration of MyRuntimeException really needs a comment explaining why it should be a RuntimeException. Extending RuntimeException unnecessarily increases the risk of failing to catch an exception in a method that should catch it. – Patricia Shanahan Aug 08 '13 at 07:43