We Keep Coding

Why is it allowed to catch subtype of a thrown exception in Java

I read in a Java book, that "Java will not allow you to declare a catch block for a checked exception type that cannot potentially be thrown by the try class body".
That makes sense so far.
But now I am asking myself why this code does compile:
try {
throw new Exception();
} catch (IOException e) {
} catch (Exception e) {
}
Java allows me to catch the IOException, but obviously it will never be thrown by the try-block.
Doesn't this example break the rule described in the Java book?

Java allows me to catch the IOException, but obviously it will never
be thrown by the try-block.
Because Exception is more general than IOException so the compiler understand that Exception can also be IOException.
Here is a contre example of what will happen if you try NumberFormatException instead of Exception
try {
throw new NumberFormatException();
} catch (IOException e) { // fail
} catch (Exception e) {
}
It fail because NumberFormatException is not general than IOException.

It is obvious to a programmer that reads this code, but i guess the compiler will deal with the throw statement the same way it would deal with a call to a method declared as throwing Exception, and in this case, the thrown exception could very well be an IOException.

Is there a way to suppress the "catch branch identical" warning? Unable to use multi catch in this instance

Working on an android application with API 17 and currently needing to do some reflection to complete a task. The ReflectiveOperationException is only available for use from API 19 and up, however this is fine since I can simply catch each exception individually.
The problem is when I do, I get a warning saying the catch branches are identical and can be written using a multi-catch (or use Exception which I'd like to avoid). But when I write the catches as a multi-catch, I get the error saying I can't use the ReflectiveOperationException class due to not being API 19.
Simply put I'd like to just suppress the warning but wasn't able to find anything that matches besides just doing #SuppressWarning("all")
For context, here are the warnings/errors:
// Error: "Multi-catch with these reflection exceptions requires API level 19 (current min is 15)
// because they get compiled to the common but new super type ReflectiveOperationException.
// As a workaround either create individual catch statements, or catch Exception."
try {
return someMethodThatThrowsExceptions();
} catch (InstantiationException | IllegalAccessException e) {
throw new RuntimeException(e);
}
// Warning: 'catch' branch identical to 'InstantiationException | IllegalAccessException' branch"
try {
return someMethodThatThrowsExceptions();
} catch (InstantiationException e) {
throw new RuntimeException(e);
} catch (IllegalAccessException e) {
throw new RuntimeException(e);
} catch (NoSuchMethodException e) {
throw new RuntimeException(e);
} catch (InvocationTargetException e) {
throw new RuntimeException(e);
}
Edit: added all the catches I was dealing with, originally only had two

#SuppressWarnings("TryWithIdenticalCatches") should do the trick.

For suppressing certain warnings I have a utility function like this:
public static <T> T get( T value )
{
return value;
}
So, you can feed e to this get() function before throwing it, thus making the two catch clauses non-equal.

Should I re-throw an exception after logging it?

I find myself coding methods that throw a specified error, but still surrounding the relevant code sections in a try catch, where I use the catch to log a localised error message and re-throw the principal one.
Here is a short example:
public void doWork(String url) throws IOException {
Object target;
try {
target = new target(url); //instantiating this object could potentially not work if the URL is malformed
} catch (MalformedURLException e) {
localErrorMessage(debug, "URL error here"); //log a local message
throw e;
} catch (IOException e) { //in some cases it can throw an IO exception if using a localised file type object.
localErrorMessage(debug, "IO error here"); //log a local message throw e;
}
}
I use this as I can turn off my localised logging (using log4j2), or use it during testing, as a debugging method.
Is this a reasonable practice, or is there a better way to do it?

order in multi-catch exception handler

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);
}

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.

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);
}

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.

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.

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.

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);
}

spring jdbcTemplate how to catch exception?

Everything is brilliant until I encounter place where I actually do need to catch exception. When I place
jdbcTemplate.query(something...)
in
try{}
block I get:
Unreachable catch block for SQLException. This exception is never thrown from the try statement body.
What do I do in this situation?
try{
personIdReturnedByDb = jdbcTemplate.queryForInt(sql, p.getEmail(),
p.getName(), p.getSurname(), encPw, dateSql);
}
catch(SQLException sa){
}
Thank You,

That's because SQLException, a checked exception, is not thrown by the any of the JdbcTemplate.query(...) methods (javadoc link). Spring translates this to one of the DataAccessException, which is more generic family of runtime exceptions, in order to abstract away any specific underlying database implementation.

You should catch the JdbcTemplate exception
i.e.
try
{
// Your Code
}
catch (InvalidResultSetAccessException e)
{
throw new RuntimeException(e);
}
catch (DataAccessException e)
{
throw new RuntimeException(e);
}

InvalidResultSetAccessException is a DataAccessException so that no need to catch it in your case.
And DataAccessException is already a RuntimeException so that no need to throw a Runtime exception.
But you should throw a specific exception of your application such as :
try
{
// Your Code
}
catch (DataAccessException e)
{
throw new MyApplicationException("A problem occurred while retrieving my data", e);
}