Htydjtk

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 caught possible to catch (you won't catch that caching 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, because you're using the same exception here. You're catching an exception to handle it. If you cannot, rethrow it.

try  {

    // Some code here

} catch (IOException e) {

    throw e;

} catch (Exception e) {

    throw e;

}

This pattern 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:

• you cannot handle a Checked Exception and you don't want to rethow it to the caller


• this exception means something different inside your business domain and should be wrapped