unreported exception handling in java

Question

I am a Java beginner and knows that try...catch statements are used to handle exceptions; means when an exception is thrown by try block, catch block is executed. So,my question is when I tried the following code (without try catch) it throws a unreported IOException in read() method but when I use try catch it works fine.

Why doesn't the control get transferred to catch statement when the above mentioned exception occurs in the try block and exception occured is printed? here is my code:

class Test00 {
    public static void main(String args[]) {
        char ch;

        try {
            ch=(char)System.in.read();//here exception is thrown without using try..catch
            System.out.println(ch);
        } catch(Exception e) {
            System.out.print("exception occured");
        }
    }
}

I think the compiler is saying to throw an exception,that's why the code worked with try catch.But why not the catch block is executed?is i am getting something wrong.

Read these links : http://www.artima.com/designtechniques/desexcept.html http://www.artima.com/designtechniques/exceptionsP.html — ritesh, Jul 04 '13 at 16:15
Are you saying that, while running the program an exception is thrown, or that the compiler, when attempting to compile the program, complains that an exception is not caught?? — Hot Licks, Jul 04 '13 at 16:16
(Hint: When reporting a problem on SO, *always* copy/paste the *exact* error messages you are getting. And when reporting a Java exception be sure to also include at least the first 10 or so lines of the stack trace.) — Hot Licks, Jul 04 '13 at 16:17
http://docs.oracle.com/javase/tutorial/essential/exceptions/ — Brian Roach, Jul 04 '13 at 16:18

score 8 · Accepted Answer · edited May 23 '17 at 12:21

The compiler is telling you that the exception could be thrown, and that you have to cater for that possibility.

The compiler is doing a static analysis of your code. It can't tell how the code will actually run in practise.

This can be frustrating. e.g. if I write:

new URL("http://www.stackoverflow.com");

the compiler will insist that I catch a MalformedURLException. It's clear that URL is fine, but the compiler warns me since I could construct a URL object using:

new URL(potentiallyDubiousUserInput);

and I can't guarantee what that string potentiallyDubiousUserInput is going to be.

These are known as checked exceptions and you have to handle them (either catch or declare them to be thrown further). They can be a pain, and you'll see in languages such as Scala that all exceptions are unchecked. That is, you don't explicitly have to handle them.

See this question/answer for more info.

And having to put that between a try-catch block could in some situations cause a little performance cost: http://stackoverflow.com/questions/16451777/is-it-expensive-to-use-try-catch-blocks-even-if-an-exception-is-never-thrown — jsedano, Jul 04 '13 at 16:19
i think Static analysis is the real term which explains me my problem. That is the compiler may have thought that user may input any integer or something else which is not desired here. — darxtrix, Jul 04 '13 at 16:40

score 1 · Answer 2 · answered Jul 04 '13 at 16:14

You have to distinguish (and tell us clearly, so that we don't have to puzzle it out) between what the compiler is telling you and what happens at runtime.

In your case, without the try-catch the compiler was telling you that the read() might throw, and that you would have to deal with the exception somehow. That's what you did by adding the try-catch.

However, when you then ran the program, it didn't actually throw (and generally speaking, it's very unlikely that this program will throw), so it never entered the catch block.

score 0 · Answer 3 · answered Jul 04 '13 at 16:44

This is because System.in.read() can throw IOException which is a checked Exception. And as mentioned in JLS 11.2.3 about checked exception:

It is a compile-time error if a method or constructor body can throw some exception class E when E is a checked exception class and E is not a subclass of some class declared in the throws clause of the method or constructor.

unreported exception handling in java

3 Answers3