Why don't you have to explicitly declare that you might throw some built in exceptions in Java?

Question

I've noticed with Integer.parseInt() that you don't have to surround it with a try catch or declare that the method might throw an exception, despite the fact that it "throws" a NumberFormatException.

Why don't I have to explicitly catch the NumberFormatException or state that my method throws it?

score 16 · Accepted Answer · edited May 23 '17 at 12:14

16

Because that is a "runtime" exception.

RuntimeExceptions are used to identify programming problems ( that a good programmer could avoid ) while

Checked exceptions are to identify environment problems ( that could not be avoided no matter how good do you program , a server is down for instance )

You could read more about them here

There are actually three kinds of exceptions, only one of them should be handled ( most of the times )

edited May 23 '17 at 12:14

Community

1
1

answered Feb 09 '09 at 16:50

OscarRyz

196,001
113
385
569

That is a bad description of the difference between runtime/checked exceptions. That is **not at all** the difference between them. There are `RuntimeException`s which you *should* catch, and there are checked exceptions which you could avoid by doing extra checks before calling the method. – Loduwijk Jul 19 '16 at 18:34
Ex1: `NumberFormatException` is one that you usually should catch. Catching `NumberFormatException` is better than trying to check the format of a `String` yourself before converting it to a number, as then you could *still* end up with a `NumberFormatException` that now you're not catching. – Loduwijk Jul 19 '16 at 18:36
Ex2: `IOException` is one that is thrown all over the place by many APIs. This is probably the most-caught exception for me and the most-caught exception I see in others' code as well. There are plenty of places where you are forced to catch `IOException` or its subclasses where it will never be thrown in some contexts of using the API that throws it. – Loduwijk Jul 19 '16 at 18:41
Ex3: `IOException` again, but this third type of situation is the opposite of #2. A file not found exception is one that you generally expect to happen on occasion depending on the user's file system. However, despite being a checked exception, technically you could check to see if the file exists before accessing it, and doing this is a very simple 1-liner. Much easier than checking a `String`'s number format. – Loduwijk Jul 19 '16 at 18:46
There are plenty of situations like these, and they are not an exception to the rule (no pun intended). In reality, whether an exception is checked or unchecked is all up to the opinion of the person(s) who creates the exception. At that point, you weigh the annoyance of a checked exception against the probability of negative consequences from an unchecked exception slipping through uncaught, and you throw in some considerations such as ease of use for devs (ex: opening files could have thrown an illegal state on file-not-found and required `File.exists` usage, but that's unwieldy). – Loduwijk Jul 19 '16 at 18:55
@Aaron While I don't completely disagree with all the comments you've added here, and certainly a lot of things have changed since I've answered this question 7 yrs ago, probably your comments would be more beneficial if they are set in a separate answer, so people who reaches this page may find them helpful. This is a 7 years old answer, and nowadays I prefer using runtime exception where possible. Yet, the answer is still correct. – OscarRyz Jul 20 '16 at 00:21

score 7 · Answer 2 · answered Feb 09 '09 at 16:53

         Throwable
         /      \
      Error    Exception
                /     \
           *checked*  RuntimeException
                            \
                         *unchecked*

See Thinking in Java for a good explanation of Checked vs. Unchecked exceptions.

Some consider the idea of checked exceptions a failed experiment. For example, both Spring and Hibernate use unchecked exceptions, and often wrap checked exceptions in unchecked versions.

score 6 · Answer 3 · answered Feb 09 '09 at 16:49

NumberFormatException extends RuntimeException, you don't have to explicitly handle anything that inherits from RuntimeException.

Other RuntimeExceptions are things like NullPointerException and IndexOutOfBoundsException. These are things the programmer can avoid and having to try/catch these types of exceptions would create some pretty cluttered code.

score 2 · Answer 4 · answered Feb 09 '09 at 18:36

Just a long comment on toolkit's answer.

The reason Checked exceptions are a problem is that they eventually lead to code like this:

try {
    Something that throws an exception
} catch (Exception e) {}

This is worst case. First of all, they are not logging that they are catching the exception. This happens a lot, and is almost FORCED by very stupid checked exceptions like the one on Thread.sleep(), it throws InterruptedException that MUST be caught, but 99% of the time you couldn't care less if you got one or not.

In the case above, it's compounded by the fact that people tend to just catch "Exception" if there are more than one thrown. That means that even if a critical unchecked exception is thrown, it will be caught and ignored making it virtually impossible to find the problem.

More than once I've been on teams that had to spend about a man-month trying to track down bugs hidden in this way.

It's a good concept that becomes horrible when you add in the fact that humans are the ones who must implement it responsibly.

Why don't you have to explicitly declare that you might throw some built in exceptions in Java?

4 Answers4

Linked