Rtrow exception in java

Question

I have a very simple question about re-throwing exception in Java.

Here is the code snippet:

public static void main(String[] args) throws FileNotFoundException { try { FileReader reader = new FileReader("java.pdf"); } catch (FileNotFoundException ex) { throw ex; } } public static void main(String[] args) throws FileNotFoundException { FileReader reader = new FileReader("java.pdf"); } 

Why do we need to transfer ex to the first version, and the second version looks more elegant? What are the benefits and which version is preferred over others?

Answer 1

You're right. The second version is better. Moreover, the first version makes no sense. It does the same, except that the exception stack trace will be "incorrect."

The following reasons exist for “re-throwing” exceptions:

• If you have something to do before.
• If you catch an exception of one type and throw an exception of another type:

Example:

 try { // do something } catch (IOException ioe) { throw new IllegalStateException(ioe); } 

Answer 2

In the above example, rethrowing an Exception has no purpose.

Doing this can be useful if a method that catches and then throws an exception needs to take additional action while viewing the Exception , and also wants the Exception be passed to the caller so that the caller can see the Exception and also take some action.

Answer 3

I would only catch / reconstruct the exception (instead of just throwing it) if I wanted to do something else in the catch block, for example, write a registration instruction before reconstructing.

Answer 4

In addition to the desire to do something with an exception before exiting - for example, to a journal, another time when you do something like this, you want to wrap it as another exception, for example:

 try { FileReader reader = new FileReader("java.pdf"); } catch (FileNotFoundException ex) { throw new ServletException(ex); } 

Answer 5

The question is why you think you need to rebuild the exception. Did Eclipse envision an environment with try-catch ? In practice, we rarely reconstruct the same exception, but very often we catch it and throw another one that wraps the first, especially if the exception of the wrapper is not noted. This happens whenever you have calls declaring checked exceptions, but the method you write these calls does not declare these exceptions:

 public int findId(String name) { try { return db.select("select id from person where name=?", name); } catch (SQLException e) { throw new RuntimeException(e); } } 

Answer 6

The thread of execution stops immediately after the throw statement; any subsequent statements are not fulfilled. In the closest try block, it is checked to see if it has a catch statement that matches the type of exception.

If he finds a match, control is transferred to this statement. If not, then the next attached try checked, and so on. If no catch match is found, then the exception handler by default stops the program and prints a stack trace.

If a method is capable of raising an exception that it does not handle, it must specify this behavior so that callers of the method can protect themselves from this exception.

This can be done by including a throws in the throws method declaration. The throws lists the types of exceptions that a method may call. This is necessary for all exceptions, except those of type Error or RuntimeException , or any of their subclasses. All other exceptions that the method can throw must be declared int in the throws . If this is not the case, a compile-time error will occur.

Answer 7

Both versions will produce the same stacktrace file

without try / catch

 import java.io.FileNotFoundException; import java.io.FileReader; public class Test { public static void main(String[] args) throws FileNotFoundException { // try { FileReader reader = new FileReader("java.pdf"); // } catch (FileNotFoundException ex) { // throw ex; // } } } 

displays

 Exception in thread "main" java.io.FileNotFoundException: java.pdf (The system cannot find the file specified) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(FileInputStream.java:195) at java.io.FileInputStream.<init>(FileInputStream.java:138) at java.io.FileInputStream.<init>(FileInputStream.java:93) at java.io.FileReader.<init>(FileReader.java:58) at Test.main(Test.java:7) 

with try / catch / throw with the same exception

 import java.io.FileNotFoundException; import java.io.FileReader; public class Test { public static void main(String[] args) throws FileNotFoundException { try { FileReader reader = new FileReader("java.pdf"); } catch (FileNotFoundException ex) { throw ex; } } } 

will be displayed exactly as before

 Exception in thread "main" java.io.FileNotFoundException: java.pdf (The system cannot find the file specified) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(FileInputStream.java:195) at java.io.FileInputStream.<init>(FileInputStream.java:138) at java.io.FileInputStream.<init>(FileInputStream.java:93) at java.io.FileReader.<init>(FileReader.java:58) at Test.main(Test.java:7) 

try / catch / throw wrap exception

The recommended approach is to throw your own exceptions. complete the exception that you just got into it if you want to provide information about the root cause (maybe wanted or not wanted)

 import java.io.FileNotFoundException; import java.io.FileReader; public class Test { public static void main(String[] args) { try { FileReader reader = new FileReader("java.pdf"); } catch (FileNotFoundException ex) { throw new RuntimeException("Error while doing my process", ex); } } } 

You can clearly see the top-level problem (my process is not completed), and the main reason that led to this (java.pdf file not found)

 Exception in thread "main" java.lang.RuntimeException: Error while doing my process at Test.main(Test.java:9) Caused by: java.io.FileNotFoundException: java.pdf (The system cannot find the file specified) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(FileInputStream.java:195) at java.io.FileInputStream.<init>(FileInputStream.java:138) at java.io.FileInputStream.<init>(FileInputStream.java:93) at java.io.FileReader.<init>(FileReader.java:58) at Test.main(Test.java:7)