Project Coin: Exception Handling Enhancements
Several enhancements have been made to the exception handling mechanism in Java 7, most notably:
- Optimized rethrow
- Multiple exceptions caught in the same catch block
- Automatic resource management (try block with resources)
Optimized Re-throw
A developer may want to handle all the exceptions thrown by a try block in a similar fashion and hence chooses to define a single catch of the base type that is generally Throwable or Exception type. If the catch block throws an exception then the exception signature would have a Throwable type, as the actual exception type is not decided by the compiler. To overcome this, the developer can add a final keyword to the argument in the catch block. This basically means that the type of the thrown exception type is the type that the runtime actually got.
Consider the following example:
public class MyExceptionClass {
public static void throwMe()
throws FileNotFoundException, ArithmeticException {
try {
throw new ArithmeticException("Error");
} catch (Exception exception) {
throw exception;
}
}
public static void main(String[] args) {
try {
throwMe();
} catch (ArithmeticException exception) {
// Handler Code
} catch (FileNotFoundException exception) {
// Handler Code
}
}
}
The above code would not compile because the throwMe method throws an Exception type, which is not defined in the throws clause of the method. One simple substitute would be to catch the appropriate exceptions in different catch blocks and rethrow the exception if required. However, if the developer wants to handle the exception in a single catch block, Java 7 provides a feature to handle this by using the following snippet in the throwMe method.
public static void throwMe() throws FileNotFoundException, ArithmeticException {
try {
// throw new ArithmeticException("ArithmeticException");
throw new FileNotFoundException("FileNotFoundException");
} catch (final Exception exception) {
throw exception;
}
}
The exception type that is thrown by the throwMe method throws one of the actual exceptions that the catch block catches at run time. This is ensured by the final keyword, which is prefixed before the exception argument. The catch block can handle the exception and throw the appropriate exception back to the caller method in the call stack.
Multiple Exceptions Caught in the Same Catch Block
If a try block threw multiple exceptions in previous versions of Java, it was the developer's responsibility to declare a catch block for each exception type. Java 7 provides a new feature: defining multiple exception types in the catch block definition. A single catch block can catch exceptions of multiple types. Here is an example:
try {
Class string = Class.forName("java.lang.String");
string.getMethod("equals");
} catch (ClassNotFoundException | NumberFormatException | IOException ex) {
// Handler Code
}
In the above example, the try block can throw an exception of type ClassNotFoundException or NumberFormatException or IOException, and these exceptions can be caught in a single catch block.
An exception to this feature is that the multi-catch does not support the exception in a hierarchy; that is, one exception class in the list cannot be a subclass of another in the list. For instance, IOException and FileNotFoundException cannot be used in the catch block clause as FileNotFoundException is a subclass of IOException.
Automatic Resource Management
This new try block syntax helps with the automatic closing of resources. The resources that are declared while defining the try block will get automatically closed when the control comes out of the try block. In the earlier versions of Java, the finally block was used to close the resources.
try (BufferedReader reader = new BufferedReader(new FileReader(fileName))) {
while ((line = reader.readLine()) != null) {
myFileContents.append(line);
myFileContents.append("\n");
}
Integer empId = Integer.parseInt(employeeId);
} catch (IOException ex) {
}
In the above code snippet, the reader object will get automatically closed when the control comes out of the try block.
Project Coin: Simplified Varargs Method Invocation
Generics, while a major advancement for the Java platform, has a major limitation: generic arrays cannot be created. The below code snippet throws a compile time error.
List<String> myList = new ArrayList<>[];
Consider a situation where a method accepts varargs arguments. The compiler gives a warning if the arguments passed to it are non-reifiable, and it can lose its type information after type-erasure. The compiler issues a warning "warning: [unchecked] unchecked generic array creation". The programmer can also suppress this warning by using the @SafeVarArgs annotation on the method, which would ensure that the method wouldn't perform any unsafe operation.
public class MyVarArgsDemoClass {
public static void main(String[] args) {
compute(new HashMap<Integer>(),
new TreeMap<Integer>());
}
@SafeVarargs
static void compute(Map<Integer>... args) {
//Some code
}
}
Conclusion
Hopefully, it has become clear that even the smaller Java 7 enhancements, which are at the heart of Project Coin, make the Java language much simpler for developers.
Acknowledgements
The author would like to sincerely thank Mr. Subrahmanya (SV, VP, ECOM Research Group, E&R) for his ideas, guidance, support and constant encouragement, and Mr. Piram for kindly reviewing the article.
Previous Page
