Ryfujk

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 original exception with original stacktrace only. You wont see this "retrhrow" line in stacktrace so its kind of transparent.

catch (IOException e) {

    throw new IllegalStateException(e);

}

You will see created IllegalStateException and its stacktrace with "caused by" original excetpion information and stacktrace. You are setting (about to be) thrown exception as cause of newly created IOException. Upper layer will see IllegalStateException and that will be caugh possible to catch (you wont catch that caching cause exception).

catch (IOException e) {

     throw new IOException();

}

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

This example doesn't make much sense because you're using the same exception here. You're catching an exception yo 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

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

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

Let's check a following a little:

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


• another class allows to rethrow or re-create exception


• afterwards, I am just printing stacktrace, compare results

Exception generator

public class ExceptionsThrow {

    public static void throwNewException() throws Exception {

        throw new Exception("originally thrown message");

    }



}

Class for re-throw/ re-create 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 original message, because I have used the same Exception to built the new one, but you dont need to do it like this, so you can mask original cause, or you dont need to expose the logic of the app, for instance lets check once more example:

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


• as you can see, newly created exception doesnt contains 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 dont tell you

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

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

===========

So, I would say, recreate exception with the same instance is 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 - eg. from IO exception to generic Exception, etc.

In 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 connection with DB was not working correctly, connection strings (including DB address and credentials in plaintext) were visible in the web browser, eg. :)