Kdtyjb

Consider:

try  {

    // Some code here

} catch (IOException e) {

    throw e;

} catch (Exception e) {

    throw e;

}

What is the difference between throw e and throw new Exception(e)?

try  {

   // Some code here

} catch (IOException e) {

   throw new IOException(e);

} catch (Exception e) {

   throw new Exception(e);

}

If you don't need to adjust the exception type, you rethrow (throw further) the same instance without any changes:

catch (IOException e) {

    throw e;

}

If you do need to adjust the exception type, you wrap e (as a cause) into a new exception of the type required.

catch (IOException e) {

    throw new IllegalArgumentException(e);

}

I consider all other scenarios a code smell. Your second snippet is a good example of it.

Here are answers to the questions that might pop up.

Why would I want to rethrow an exception?

You can let it go. But if it happens, you won't be able to do anything at this level.

When we catch an exception in a method, we are still in that method and have access to its scope (e.g. local variables and their state). Before we rethrow the exception, we can do whatever we need to (e.g. log a message, send it somewhere, make a snapshot of the current state).

Why would I want to adjust an exception?

As a rule of thumb,

Higher layers should catch lower-level exceptions and, in their place, throw exceptions that can be explained in terms of the higher-level abstraction.

_{Effective Java - 2nd Edition - Item 61: Throw exceptions appropriate to the abstraction}

In other words, at some point, an obscure IOException should be transformed into a perspicuous MySpecificBusinessRuleException.

_{I called it "adjusting the exception type", smart guys call it exception translation (exception chaining, in particular).}

To make it clear, let's have some folly examples.

class StupidExample1 {

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

        try {

            throw new IOException();

        } catch (IOException e) {

            throw new IOException(new IOException(e));

        }

    }

}

results in a verbose stack trace like

Exception in thread "main" java.io.IOException: java.io.IOException: java.io.IOException

    at StupidExample1.main(XXX.java:XX)

Caused by: java.io.IOException: java.io.IOException

    ... 1 more

Caused by: java.io.IOException

    at StupidExample1.main(XXX.java:XX)

which can (and should) be effectively reduced to

Exception in thread "main" java.io.IOException

    at StupidExample1.main(XXX.java:XX)

Another one:

class StupidExample2 {

    public static void main(String[] args) {

        takeString(new String(new String("myString")));

    }



    static void takeString(String s) { }

}

It's obvious that new String(new String("myString")) is a wordy version of "myString".

catch (IOException e) {

    throw e;

}

You will see the original exception with the original stacktrace only. You won't see this "rethrow" line in the stacktrace so it's kind of transparent.

catch (IOException e) {

    throw new IllegalStateException(e);

}

You will see created IllegalStateException and its stacktrace with "caused by" original exception information and stacktrace. You are setting (about to be) the thrown exception as the cause of the newly created IOException. The upper layer will see IllegalStateException and that will be possible to catch (you won't catch that catching cause exception).

catch (IOException e) {

     throw new IOException();

}

You will see only the current stacktrace of the IOException creation, no the cause added.

Well, basically, throw e will "rethrow" all original values- also some code-flow, which should be hidden, for example, security reason for instance. If you will re-create the exception, you will get - or you can get - another stacktrace in the place.

So, I would say, you have option to mask some data (don't know, you can for example log exceptions into a special log, but you will want to pass other diagnostic data into end-user).

Let's check the following a little:

• I created one class as just only simple generator of Exceptions


• another class allows to rethrow or recreate exception


• afterwards, I am just printing the stacktrace and compare results

Exception generator

public class ExceptionsThrow {

    public static void throwNewException() throws Exception {

        throw new Exception("originally thrown message");

    }

}

Class for rethrow/ recreate exceptions

  public class Exceptions {



        public static void reThrowException() throws Exception {

            try {

                ExceptionsThrow.throwNewException();

            } catch (Exception e) {

                throw e;

            }

        }



        public static void reCreateNewException() throws Exception {

            try {

                ExceptionsThrow.throwNewException();

            } catch (Exception e) {

                throw new Exception(e);

            }

        }

    }

Testing code example:

try {

     Exceptions.reThrowException();

} catch (Exception e) {

    System.out.println("1st RETHROW");

    e.printStackTrace();

    System.out.println("===========");

}



try {

    Exceptions.reCreateNewException();

} catch (Exception e) {

    System.out.println("2nd RECREATE");

    e.printStackTrace();

    System.out.println("===========");

}

And the output finally:

1st RETHROW

java.lang.Exception: originally thrown message

    at test.main.stackoverflow.ExceptionsThrow.throwNewException(ExceptionsThrow.java:5)

    at test.main.stackoverflow.Exceptions.reThrowException(Exceptions.java:7)

    at test.main.MainTest.main(MainTest.java:110)

java.lang.Exception: java.lang.Exception: originally thrown message===========

2nd RECREATE



    at test.main.stackoverflow.Exceptions.reCreateNewException(Exceptions.java:17)

    at test.main.MainTest.main(MainTest.java:118)

Caused by: java.lang.Exception: originally thrown message

    at test.main.stackoverflow.ExceptionsThrow.throwNewException(ExceptionsThrow.java:5)

    at test.main.stackoverflow.Exceptions.reCreateNewException(Exceptions.java:15)

    ... 1 more

===========

In this case, you can see mostly the same data, but some additional, you can see the original message, because I have used the same Exception to built the new one, but you don't need to do it like this, so you can mask original cause, or you don't need to expose the logic of the application, for instance let’s check one more example:

• I will take only the cause from the original exception, but it will override the data


• as you can see, a newly created exception doesn't contain the full stacktrace, as the
  origin

So:

public static void maskException() throws Exception {

    try {

        ExceptionsThrow.throwNewException();

    } catch (Exception e) {

        throw new Exception("I will dont tell you",e.getCause());

    }

}

And the result:

===========

3rd mask

java.lang.Exception: I will don't tell you

    at test.main.stackoverflow.Exceptions.maskException(Exceptions.java:25)

    at test.main.MainTest.main(MainTest.java:126)

===========

So, I would say, recreate the exception with the same instance is a little pointless, but there can be cases when you want to do it like that - mask data, or another case can be as well if you want to change Exception type - for example, from an I/O exception to a generic Exception, etc.

In the real world, I can remember the really often issue, when some web portals, handled exceptions in PHP scripts only by this case of printing, and then usually, when the connection with the database was not working correctly, connection strings (including database address and credentials in plaintext) were visible in the web browser, for example. :)

This example doesn't make much sense in this context, because you're throwing the same exception and not doing anything else. Logging it at least will make much more sence. You're catching an exception to handle it or log it. If you cannot handle it, rethrow it (case 1) or wrap to something else (case 2).

Case 1:

public class Main {



    // forced to handle or rethrow again

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

        read();

    }



    public static void read() throws IOException {

        try {

            readInternal();

        } catch (IOException e) {

            throw e;

        }

    }



    private static void readInternal() throws IOException {

        throw new IOException("Output error");

    }

}

In the output you'll see something like:

Exception in thread "main" java.io.IOException: Output error

    at com.alex.java.Main.readInternal(Main.java:26)

    at com.alex.java.Main.read(Main.java:19)

    at com.alex.java.Main.main(Main.java:14)

**Case 2:**

The pattern below allows you to change the type of the exception and keep the original exception details as well:

try {

   // Some code here

} catch (IOException e) {

    throw new IllegalStateException(e);

}

This case often happens when you would like to substitute a Checked Exception with an Unchecked exception preserving the origination of the issue and keep all the information (what called exception chaining).

Regular use-cases:

• You cannot handle a Checked Exception and you don't want to rethow it to the caller. Rethoring checked exceptions will force the caller to handle it. This is not what you want to do if there is no regular cases for recovery.


• Exceptions like IOException are rarely useful to the client. You need to send something more specific and clear in scope of you business domain.

IOException wrapped to Unchecked Exception like DocumentReadException will shed light on actual situation and will not force the callers to handle it:

public class Main {



    public static void main(String[] args) {

        read();

    }



    public static void read() {

        try {

            readInternal();

        } catch (IOException e) {

            // log and wrap the exception to a specific business exception

            logger.error("Error reading the document", e);

            throw new DocumentReadException(e);

        }

    }



    private static void readInternal() throws IOException {

        throw new IOException("Output error");

    }

}

The output will be similar to:

Exception in thread "main" java.lang.IllegalArgumentException: Error reading the document

    at com.alex.java.Main.read(Main.java:21)

    at com.alex.java.Main.main(Main.java:14)

Caused by: java.io.IOException: Output error

    at com.alex.java.Main.readInternal(Main.java:26)

    at com.alex.java.Main.read(Main.java:19)

    ... 1 more

As you can see from the stack-trace, the root cause was logger to help you find out the original problem and the business domain exception was sent to a user.