order in multi-catch exception handler

Question

I know since Java 7 you can use multi-catch but I wonder if the order of exceptions in it matters like in previous versions of java? E.g I put in Exception and then SQLException and IOException ?

try {
      // execute code that may throw 1 of the 3 exceptions below.

} catch(Exception | SQLException | IOException e) {   
    logger.log(e);

}

Or should I do it this way ?

try {

    // execute code that may throw 1 of the 3 exceptions below.

} catch(SQLException | IOException e) {
    logger.log(e);

} catch(Exception e) {
    logger.severe(e);
}

Laboured

Answer 1

There's no point in a single catch block for catch(Exception | SQLException | IOException e) since Exception already covers its sub-classes IOException and SQLException.

Therefore catch(Exception e) would be enough if you wish the same handling for all of those exception types.

If you want different handling for the more general Exception, your second code snippet makes sense, and here the order of the two catch blocks matters, since you must catch the more specific exception types first.

Teodorateodorico

Answer 2

Yes Order is important, it is from Child to Parent.

Refer this for more such.

The exception variable is implicitly final, therefore we cannot assign the variable to different value within the catch block. For example, the following code snippet will give a compile error

} catch (IOException | SQLException ex) {

    ex = new SQLException();

}

The compiler will throw this error: multi-catch parameter ex may not be assigned

It is not allowed to specify two or more exceptions of a same hierarchy in the multi-catch statement. For example, the following code snippet will give a compile error because the FileNotFoundException is a subtype of the IOException

} catch (FileNotFoundException | IOException ex) {

    LOGGER.log(ex);

}

The compiler will throw this error (no matter the order is): Alternatives in a multi-catch statement cannot be related by subclassing

The Exception class is the supertype of all exceptions, thus we also cannot write

} catch (IOException | Exception ex) {

    LOGGER.log(ex);

}

Bunkum

Answer 3

Multi catch feature is provided in java to remove code duplication in two different hierarchical exceptions. If you are using it for this reason the ordering does not matter. If you are catching parent exception class Exception in multi catch block, then there is no need to add child exception IOException, SQLException classes.

Kidron

Answer 4

The multicatch Exceptiontypes are separated by an 'OR', so no, the order doesn't matter.

You should only use the multicatch if you plan to have all the Exceptiontypes be handled the same way anyway, and if that's the case, the order doesn't matter.

EDIT: indeed, if the types are in a hiërarchical line, only the 'alternative' (in this case the generic Exception) type should be caught. This has nothing to do with their order, though.

Stephi

Answer 5

The order matters, because if you try to catch Exception first, and your second catch is for IOException, obviously you'll never hit the second catch. So the order must be from the smallest Exception to the biggest.

Thinnish

Answer 6

The Exceptions have some hierarchy. Exception e is more objective than others, because of that, it should be last exception that you handle.

There are no comparison between IOException and SQLException, because of that, you can handle them whatever you want.

So, the order should be:

try {

// execute code that may throw 1 of the 3 exceptions below.

} catch(SQLException | IOException e) {
     logger.log(e);

} catch(Exception e) {
     logger.severe(e);
}

or

try {

// execute code that may throw 1 of the 3 exceptions below.

} catch(SQLException e) {
     logger.log(e);

} catch(IOException e){
     logger.log(e);

} catch(Exception e) {
     logger.severe(e);
}

or

try {

// execute code that may throw 1 of the 3 exceptions below.

} catch(IOException e) {
     logger.log(e);

} catch(SQLException e){
     logger.log(e);

} catch(Exception e) {
     logger.severe(e);
}

Outcurve