Java 7 improved exception handling

There are two improvements in exception handling - multicatch and final re throwing. To see how they can help us, first look at a piece of Java 6 code. The following code attempts to find, open, analyze the configuration file and handle various exceptions that may occur during this process:

Handling different exceptions in Java 6

public Configuration getConfig(String fileName) {
 Configuration cfg = null;
 try {
  String fileText = getFile(fileName);
  cfg = verifyConfig(parseConfig(fileText));
 } catch (FileNotFoundException fnfx) {
  System.err.println("Config file '" + fileName + "' is missing");
 } catch (IOException e) {
  System.err.println("Error while processing file '" + fileName + "'");
 } catch (ConfigurationException e) {
  System.err.println("Config file '" + fileName + "' is not consistent");
 } catch (ParseException e) {
  System.err.println("Config file '" + fileName + "' is malformed");
 }
 return cfg;
}

This method will encounter the following exceptions:

These exceptions can be divided into two categories. One is that the file is lost or damaged in some way, and the other is that although the file theoretically exists and is correct, it cannot be read normally (possibly due to network or hardware failure).

It would be better if these exceptions could be simplified into these two categories, and all exceptions of "file lost or damaged in some way" could be handled in one catch statement. You can do this in Java 7:

Handling different exceptions in Java 7

public Configuration getConfig(String fileName) {
 Configuration cfg = null;
 try {
  String fileText = getFile(fileName);
  cfg = verifyConfig(parseConfig(fileText));
 } catch (FileNotFoundException|ParseException|ConfigurationException e) {
  System.err.println("Config file '" + fileName +
            "' is missing or malformed");
 } catch (IOException iox) {
  System.err.println("Error while processing file '" + fileName + "'");
 }
 return cfg;
}

The exact type of exception e is not known at compile time. This means that in the catch block, it can only be treated as the common parent of possible exceptions (exception or throwable are often used in actual coding).

Another new syntax can help re throw exceptions. Developers often have to deal with the exception before throwing it again. In previous versions of Java, you can often see the following code:

try {
 doSomethingWhichMightThrowIOException();
 doSomethingElseWhichMightThrowsqlException();
} catch (Exception e) {
 ...
 throw e;
}

This forces you to declare the newly thrown exception as an exception - the real type of the exception is overwritten.

Anyway, it's easy to see that the exception can only be IOException or sqlexception. Since you can see, so can the compiler. The following code uses the syntax of Java 7, with only one word changed:

try {
 doSomethingWhichMightThrowIOException();
 doSomethingElseWhichMightThrowsqlException();
} catch (final Exception e) {
 ...
 throw e;
}

The keyword final indicates that the exception actually thrown is the exception encountered at runtime -- in the above code, it is IOException or sqlexception. This is called final re throw, so that general exception types will not be thrown, so as to avoid being caught only with general catch at the upper level.

The keyword final in the above example is not required, but in fact, it can be kept as a reminder during the transition to catch and re throw semantic adjustment.

The improvement of exception handling in Java 7 is not limited to these general problems, but also improves the specific resource management, which we will talk about shortly.

The above is all the knowledge points introduced this time. I hope the contents we sorted out can help you.