CodeGym/Help with Java Tasks/Why is the throws IOException required in line 14???

Level 27

15.02.2022
477views
12comments

Why is the throws IOException required in line 14???

Question about the task

Under discussion

The task gets us to take a pre-Java 7 try-catch-finally and update it using a try-with-resources. The code shown below is the task is in its untouched original form hence the errors shown when it is verified. I noticed on Line 14

public static void main(String[] args) throws IOException {

On line 25 & 26

catch (IOException e) {
            System.out.println("Something went wrong : " + e);

Question Why is the throws IOExeception on line 14 required when the purpose of the try-catch block is to catch IOExeception? I note on the Solution for the task the throws IOExeception is omitted and works fine but if you remove it in the task it reports an uncaught IOException. Any thoughts?

The program reads from the console the path to a file, reads lines from the file, and displays them on the screen.
Rewrite the code using try-with-resources: create objects that use external resources inside the parentheses. Remember to remove the unnecessary finally block and the calls to the close() method.

Requirements:

The program should read the path to a file from the console, then read lines from the file and display them on the screen.
The program must use the try-with-resources statement as outlined in the task conditions.
The try-with-resources statement must not have a finally block.
The close() method must not be explicitly called on objects that use external resources.
Do not use the following classes from the java.io package: File, FileInputStream, FileOutputStream, FileReader, FileWriter.

package en.codegym.task.pro.task15.task1503; import java.io.BufferedReader; import java.io.IOException; import java.nio.file.Files; import java.nio.file.Path; import java.util.Scanner; /* There are a lot of resources */ public class Solution { public static void main(String[] args) throws IOException { Scanner scanner = null; BufferedReader bufferedReader = null; try { scanner = new Scanner(System.in); String fileName = scanner.nextLine(); bufferedReader = Files.newBufferedReader(Path.of(fileName)); String line; while ((line = bufferedReader.readLine()) != null) { System.out.println(line); } } catch (IOException e) { System.out.println("Something went wrong : " + e); } finally { if (scanner != null) { scanner.close(); } if (bufferedReader != null) { bufferedReader.close(); } } } }

Comments (12)

Popular
New
Old

You must be signed in to leave a comment

Guadalupe Gagnon

Level 37 , Tampa, United States

15 February 2022, 18:02

Because line 32, which is outside the try block, can throw an IOException

Jcode

Level 27 , United Kingdom

15 February 2022, 18:57

Thanks Guadalupe for your reply. I noticed in IntelliJ line 32 gets flagged as requiring exception handling and the following works:-

finally {
            if (scanner != null) {
                scanner.close();
            }
            if (bufferedReader != null) {
                try {
                    bufferedReader.close();
                } catch (IOException e) {
                    System.out.println(e);
                }
            }
        }

I guess the follow on question is ... if the pre-java 7 allows us to handle exceptions in the finally block. What happens to those exceptions with the try-with-resources, when we no longer use the finally?

Guadalupe Gagnon

Level 37 , Tampa, United States

15 February 2022, 19:24

useful

The try-with-resources is an auto closing construct and the catch clause will catch any exception that occur on closing. Remove the catch clause and you will get red squiggly lines informing you that it needs to catch the exception on close. See picture:

Guadalupe Gagnon

Level 37 , Tampa, United States

15 February 2022, 19:36

useful

Most of the time programmers used the finally block to close Streams, that is why try-with-resources was implemented as part of the language. However T-W-R will work with any class that implements the AutoCloseable interface. Design wise, you can still use a finally block with T-W-R, but if it is going to be used for the same task in multiple code locations it may be a "better" design choice to create custom classes that implement the AutoCloseable interface that do the necessary work that the finally block was doing instead of having to retype duplicate code.

Jcode

Level 27 , United Kingdom

15 February 2022, 20:00

That makes sense! So T-W-R just redirects or throws the exception back up to the catch block where you(the programmer) can deal with it ... that's great why didn't they think of that in the first place😁 The old way of closing resources looked messy but then also needing to catch exceptions in the finally block made it even worse.

Gellert Varga

Level 23 , Szekesfehervar, Hungary

15 February 2022, 21:15

Hi Lupe! There may indeed be a case where within the finally block, do we need another catch block? (Assume we use the finally block only for to close the streams.)

Lisa

Level 41

15 February 2022, 21:37

No, the try with resource streams get closed automatically when you leave the catch block. As the resource can not be declared outside, its scope is only inside the catch block. Even if you wanted to, the resource is not valid anymore inside the finally block. Of course you could use code that throws not try-with-resource dependent exceptions. For that you may want to have another catch block inside the finally block.

// not possible
// InputStream in;
// try (in = System.in) {
try (InputStream in = System.in) {
    // scope of the try-with-resources object
} catch (IOException e) {
    // in outside its scope
} finally {
    // in outside its scope
}

Guadalupe Gagnon

Level 37 , Tampa, United States

15 February 2022, 21:45

I don't know if you misworded that question or are asking if catch blocks can be inside or part of finally blocks. If that is the question you are asking then no, catch blocks are for try blocks only and not for finally:

try {

} catch {

} finally {

} catch { } // this line will have an error

The finally block doesn't catch exceptions, it is code that executes after the try/catch block that it is attached to resolves. Therefore any code in the finally block that would normally require a try/catch block will still need it.

Gellert Varga

Level 23 , Szekesfehervar, Hungary

16 February 2022, 20:54

Thanx Lisa! But You wrote: "As the resource can not be declared outside, its scope is only inside the catch block." but your code example suggests that: "its scope is only inside the try block" I guess the latter is more correct?

Gellert Varga

Level 23 , Szekesfehervar, Hungary

16 February 2022, 20:55

Thank you Lisa and Lupe, both your replies were helpful. I apologize to both of you, because I seem to have asked the question in a very imprecise, slap-dash manner. I will now try to be more precise in my question. Suppose we have such a code:

BufferedReader bfr = null;
String st;

try {
   bfr = new BufferedReader(new FileReader(fileName));
   st = bfr.readLine();
}
catch (Exception e) {
}
finally {
    if (bfr != null) {
        bfr.close();
    }
}

In this code, if I want to be really careful, should I wrap the bfr.close() statement on line 12 in a separate try-block structure? Like this? :

finally {
    if (bfr != null) {
        try {
            bfr.close();
        }
        catch (Exception e) {
        }
    }
}

But now that I've tried the program, I can see the answer... because that's what the IDE said: "unreported exception IOException; must be caught or declared to be thrown" Maybe it was just very unusual for me, and I just found it hard to believe that so many try-catch blocks are needed...

Lisa

Level 41

16 February 2022, 22:30

I thought your question was related to try-with-resources. If it is possible somehow to close a try-with-resources resource inside the finally block. That is not possible cause the try-with-resources scope is only inside the catch block. One might think you just could declare the variable outside the try-with-resources parentheses (like in my comments above) so that its scope is more global. But that is no legal code.

// that's not valid code
InputStream in;
try (in = System.in) {
    ....

in theory you'd have access to in inside the finally block. But the Java creators forbid that.

Jcode

Level 27 , United Kingdom

16 February 2022, 23:24

Gellert, 'Maybe it was just very unusual for me, and I just found it hard to believe that so many try-catch blocks are needed...' I, too, was surprised, hence the question. It only really came to light when I removed the throws IOException in the main method,

public static void main(String[] args) throws IOException {

When you look again, it is less of a surprise, as finally contains a close statement that may not work and may throw an exception. You probably already know this, but the official documentation shows you which exceptions you should check for. I'm trying to make the official documentation my first choice rather than getting dragged into Stackoverflow. In this example of close()link