异常处理错误：使用Java？

Question

Suppose that you must use methods in Connection class supplied by a software vendor. The documentation indicates the following method declaration:

public String getData(String command) throws IOException

The following code attempts to use the getData method to obtain data in String format and output the data to the output console. But the IDE indicates the code has an exception handling related error.

public void processData(Connection conn, String command) {
  String res = conn.getData(command);
  System.out.println(res);
}

How do I fix the error?

Answer 1

The easy way is to simply tell Java that this code can throw the exception:

public void processData(Connection conn, String command) throws IOException {
  String res = conn.getData(command);
  System.out.println(res);
}

But you could also catch the exception yourself:

public void processData(Connection conn, String command) {
  try {
    String res = conn.getData(command);
    System.out.println(res);
  } catch(IOException e) {
    e.printStackTrace();
  }
}

Answer 2

Catch the exception (if you know how to properly handle the exception):

try {
    String res = conn.getData(command);
    System.out.println(res);
} catch (IOException e) {
    // handle it
}

Or, put an exception specification on this method:

public void processData(Connection conn, String command) throws IOException

Answer 3

☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠

DON'T DO IT ANTIPATTERN!

☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠ ☠

try {
    String res = conn.getData(command);
    System.out.println(res);
} catch (IOException e) {
    throw new RuntimeException(e);
}

Answer 4

You have basically two good choices:

Choice 1:
If you can reasonably handle the exception, then do so:

try {
    String res = conn.getData(command);
} catch (IOException e) {
    // do something sensible, perhaps return null or a default value etc
}

This is usually a good option if it makes sense, because it doesn't put any burden on the caller to handle exceptions

Choice 2:
IF you can't reasonably handle the exception, have your method throw an exception. The design issue here is what Exception do you throw?

If the exception "fits well" with the rest of your code, simply declare your method to throw the exception expected from the 3rd party library:

public void processData(Connection conn, String command) throws IOException

However, often when calling a 3rd party library, the exception it throws isn't compatible with your application. In your case, IOException may be completely outside the domain of your application, thrown only because the 3rd party's implementation accesses a remote server (for example), and to throw IOException would introduce a new exception to your code that doesn't "fit well" with its purpose (eg your application may have nothing to do with using a remote server).

In these cases it is best to wrap the exception in a domain exception and throw that instead. For example:

public void processData(Connection conn, String command) throws ProcessingException
    try {
        String res = conn.getData(command);
    } catch (IOException e) {
        throw new ProcessingException(e);
    }
}

To achieve this, you would create such an Exception class:

public class ProcessingException extends Exception {}

Now you have a further choice. If the exception is not expected to ever happen, in other words you have taken reasonable steps to ensure it doesn't (by making sure the environment is correct etc), you have the option of throwing an unchecked exception:

public void processData(Connection conn, String command)
    try {
        String res = conn.getData(command);
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

This version is basically saying that the exception isn't expected, and we aren't going to code for it because the situation isn't recoverable at any level, so just let it blow up and it will bubble up the calls stack until something catches Exception .

This is not an "anti-pattern", because it's right alongside with NullPointerException and all the other common unchecked exceptions, and we don't catch those either.