Develop Reference

What happens when both catch block and finally block throw exception in Java?

Consider this question I was asked in an interview
public class Test_finally {
private static int run(int input) {
int result = 0;
try {
result = 3 / input;
} catch (Exception e) {
System.out.println("UnsupportedOperationException");
throw new UnsupportedOperationException("first");
} finally {
System.out.println("finally input=" + input);
if (0 == input) {
System.out.println("ArithmeticException");
throw new ArithmeticException("second");
}
}
System.out.println("end of method");
return result * 2;
}
public static void main(String[] args) {
int output = Test_finally.run(0);
System.out.println(" output=" + output);
}
}
Output of this program throws ArithmeticException not UnsupportedOperationException
Interviewer simply asked how will i let the client know the original exception raised was of type UnsupportedOperationException not ArithmeticException.
I didn't know that

Never return or throw in a finally block. As an interviewer i would expect that answer.
A crappy interviewer looking for a minor technical detail might expect you know Exception.addSuppressed(). You can not actually read the thrown exception in a finally block so you need to store it in the throw block to reuse it.
So something like that:
private static int run(int input) throws Exception {
int result = 0;
Exception thrownException = null;
try {
result = 3 / input;
} catch (Exception e) {
System.out.println("UnsupportedOperationException");
thrownException = new UnsupportedOperationException("first");
throw thrownException;
} finally {
try {
System.out.println("finally input=" + input);
if (0 == input) {
System.out.println("ArithmeticException");
throw new ArithmeticException("second");
}
} catch (Exception e) {
// Depending on what the more important exception is,
// you could also suppress thrownException and always throw e
if (thrownException != null){
thrownException.addSuppressed(e);
} else {
throw e;
}
}
}
System.out.println("end of method");
return result * 2;
}

Get exception instance class name

I would like to know what the exception instance was in this situation:
try {
// some risky actions
} catch (Exception e) {
System.out.println("Get instance name there");
}
How can I achieve this?

Here you go:
try {
throw new ArithmeticException();
} catch (Exception e) {
System.out.println( e.getClass().getCanonicalName());
}
Output:
java.lang.ArithmeticException

The type of the exception is shown as part of the output of:
e.printStackTrace();
To get it programmatically you can use:
String exceptionClassName = e.getClass().getName();
It is poor form to have logic depending on exception sub types within a catch block. Sonar will flag this as a code violation (squid S1193).
Instead you should add multiple catch blocks to catch different types of exceptions:
try {
readFile(fileName);
}
catch (java.io.IOException e) {
LOG.error("Error accessing file {}", fileName, e);
}
catch (java.lang.IllegalArgumentException e) {
LOG.error("Invalid file name {}", fileName, e);
}
Note: Since Log4j 2 (and SLF4J 1.6+) you can add a throwable as the last parameter and it will be recognized as such. So the above will work!
Since Java 7 you can also do a multi-catch:
}
catch (java.io.IOException | java.lang.IllegalArgumentException e) {
LOG.error("Could not read the file {}", fileName, e);
}
The benefit of the multi-catch is that you can handle multiple exception types within a single catch block without having to revert to a common super class (like java.lang.Exception) that would include exception types you didn't want to handle.

Default exception logging is something like
try
{
//
}
catch (Exception e)
{
e.printStackTrace();
}
This will print the stacktrace of the exception to system.err

If you are looking to add some contextual information, you can take a look at Apache Commons ContextedRuntimeException
public static void main(String[] args) {
try {
doSomething();
} catch (ContextedRuntimeException e) {
System.out.println(e.getMessage());
System.out.println(e.getContextEntries());
}
}
private static void doSomething() {
int divisor = 0;
int dividend = 100;
int result;
try {
result = dividend / divisor; // Just throw an exception to test things....
System.out.print("DIVISION RESULT: "+result);
} catch (ArithmeticException e) {
throw new ContextedRuntimeException("Oops..division by zero not allowed", e)
.addContextValue("Divisor", divisor)
.addContextValue("Dividend", dividend);
}
}
would output:
Oops..division by zero not allowed
Exception Context:
[1:Divisor=0]
[2:Dividend=100]
---------------------------------
[(Divisor,0), (Dividend,100)]

Catch assert false using reflection

The code in the file to test is:
public void testFail() {
assert false;
}
I need to catch this using reflection and increment a "failed" counter. This is my attempt:
try {
Object t = c.newInstance();
m[i].invoke(t, new Object[0]); // m is the array that holds all Methods for c
passed ++;
} catch (AssertionError ae) {
failed ++;
} catch (Exception e) {
errors ++;
}
}
The assertFalse just goes through as passed and does not raise any exceptions. How can I catch this?
Thanks.

DRY for Exception Wrapping

I'm working on some server-side code that wraps all exceptions before passing them to the client side, due to this all client facing methods have the following code
try{
DoSomething();
} catch (ExceptionA e) {
throw new CustomException(AType, e);
} catch (ExceptionB e) {
throw new CustomException(BType, e);
} catch (Exception e) {
throw new CustomException(Unexpected, e);
}
to have this repeated in every method seems to violate the DRY principle and I was wondering what the best way to refactor it would be. For instance I was thinking a wrapper method such as:
private void wrapException(Exception e) {
if (e instanceof ExceptionA) {
throw new CustomException(AType, e);
}
etc...

Take a look at AspectJ soften exception.
Also look at Guava's Throwables.
There is also Lamboks sneaky exception.
The other option is to use Anonymous object instances aka closures.
public abstract class Wrapper {
public void execute() {
try {
// do some boiler plate before
this.wrap();
// do some boiler plate after.
} catch (ExceptionA | ExceptionB ex) {
Type t = determineType(ex);
throw new CustomException(t, ex);
}
}
public void abstract wrap();
}
Now in your code you do something like:
new Wrapper() {
public void wrap() {
DoSomething();
}
}.execute()

This is possible in Java7 and up:
http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html
Copy-paste example from above doc:
catch (IOException|SQLException ex) {
logger.log(ex);
throw ex;
}

This is one way to go about it:
Exception caughtEx = null;
String extraInfo = null;
try{
DoSomething();
} catch (ExceptionA e) {
caughtEx = e;
extraInfo = AType;
} catch (ExceptionB e) {
caughtEx = e;
extraInfo = BType;
} catch (Exception e) { // catching Exception is usually a bad idea, just let it bubble up without catching...
caughtEx = e;
extraInfo = Unexpected;
}
if (caughtEx != null) throw new CustomException(extraInfo, caughtEx);

Several "ChildException" catch blocks versius one "Exception" catch block

What's better between several ChildException catch blocks and one Exception catch block? By better, I mean in a good-practices way.
To illustrate:
public static void main(String[] args) {
System.out.println(Main.isNonsense1(null)); // false <- bad
System.out.println(Main.isNonsense2(null)); // NullPointerException <- good
}
// More readable, less precise
public static boolean isNonsense1(String className) {
try {
Class.forName(className);
String.class.getConstructor(String.class);
className.getBytes("UTF-8");
MessageDigest.getInstance("SHA-1").wait();
return true;
} catch (Exception e) {
return false;
}
}
// Less readable, more precise
public static boolean isNonsense2(String className) {
try {
Class.forName(className);
String.class.getConstructor(String.class);
className.getBytes("UTF-8");
MessageDigest.getInstance("SHA-1").wait();
return true;
} catch (ClassNotFoundException e) {
return false;
} catch (NoSuchMethodException e) {
return false;
} catch (SecurityException e) {
return false;
} catch (UnsupportedEncodingException e) {
return false;
} catch (NoSuchAlgorithmException e) {
return false;
} catch (InterruptedException e) {
return false;
}
}

This is related to this question: Catch multiple exceptions at once?
The answer there is good. The key is that if you catch Exception then you should handle each of the cases that you are aware of and throw all the rest. That is, simply catching Exception in your example and returning false would not be a good idea. You may inadvertently catch some exception you didn't mean to.
Using your example, here is my suggested code:
public static boolean isNonsense2(String className) {
try {
Class.forName(className);
String.class.getConstructor(String.class);
className.getBytes("UTF-8");
MessageDigest.getInstance("SHA-1").wait();
return true;
} catch (Exception e) {
if (e instanceof ClassNotFoundException
|| e instanceof NoSuchMethodException
|| e instanceof SecurityException
|| e instanceof UnsupportedEncodingException
|| e instanceof NoSuchAlgorithmException
|| e instanceof InterruptedException) {
return false;
} else {
throw e;
}
}
}

I think there is no complete clear answer. In your case I would code it like this:
public static boolean isNonsense1(String className) {
if(slassname==null) throw new IllegalArgumentException("className must not be null");
try {
Class.forName(className);
String.class.getConstructor(String.class);
className.getBytes("UTF-8");
MessageDigest.getInstance("SHA-1").wait();
return true;
} catch (ClassNotFoundException e) {
throw new IllegalArgumentException("provided class " + className + " not found");
} catch (Exception e) {
return false;
}
}
For my flavor, throwing a NullPointerException is always bad, thats why I throw the IllegalArgumentException

If you are not interested in handling the exception (which you should as per best practices) don't bother with the explicit catches. The whole point of being able to handle specific exceptions is to enable you to handle them correctly.