如何处理Java中一个方法抛出的异常到另一个方法中？

Question

Let's suppose I have this class:

public class Obj1{

...

 public void do_Something(int someParameter) throws SomeException {
     if(...) throw new SomeException();
...
 }
...
}

then, somewhere

public class Obj2{
...
  public void do_SomeOtherThing(Obj1 obj1){
    obj1.do_Something();
    //apparently the only solution is try-catching it directly, even if I'm not in the main...
...
}

I've learned that exceptions should only be thrown by METHOD, and catched by MAIN, so, my question is: is try-catch the unique way to handle sub-method exceptions, or the most external method (do_SomeOtherThing) will throw it, so that I can try-catch it directly in main, deleting the try-catch in Object2 class?

Basically, can I do as follows?

public static void main(String[] args){
  Object1 obj1 = new Object1();
  Object2 obj2 = new Object2();
  try{
    obj2.do_SomeOtherThing(obj1);
  }
  catch(SomeException e){
   ...
  }
}

or not?

Answer 1

A checked exception is part of the contract that a method has with its caller, and a thrown exception will always need to be handled one way or another.

The correct answer depends on the exact situation:

1. The caller can handle the exception:

String getStringFromRemoteServer() throws IOException { ... }

String getConfigString() {
  try {
    return getStringFromRemoteServer();
  } catch (IOException e) {
    LOG.warn("Failed to contact server, using local version.", e);
    return getLocalString();
  }
}

In this case we have an alternative source of the data we need, so if the preferred method fails we catch the exception, log it (so that we know a problem exists with our network) and call the alternative.

2. The exception is fatal, and we don't want any function higher in the call tree to try to handle it.

Configuration parseConfiguration(String configString) throws ParseException { ... }

void loadConfiguration() {
  try {
    this.globalConfig = parseConfiguration(getConfigString());
  } catch (ParseException e) {
    throw new RuntimeException("Corrupted config", e);
  }
}

In this case an exception means that the configuration of our application is fatally broken. There is no point in trying to handle this error, and no point in any of our callers trying to handle it, so declaring throws on loadConfiguration() would just be confusing clutter. We wrap the exception in a RuntimeException and rethrow it. Note that we don't log it -- there will be some top level reporting of uncaught exceptions, so logging it here would be repetition.

It is still valuable to have parseConfiguration() throw a checked exception, because when we are calling it from the interactive configuration editor we catch the exception and display an error message to the user.

3. Maybe our caller can handle the exception.

int stringToInteger(String s) throws BadNumberException { ... }

String decimalStringToHexString(String s) throws BadNumberException {
  return intToHex(stringToInteger(s));
}

In this case we are not changing the meaning of the exception -- decimalStringToHexString is converting a number from a string, and one possible outcome is that the string is illegal. Our caller needs to be aware of that as a possible outcome, just as callers of stringToInteger() are, so we simply declare the exception and let our caller handle it. Our caller knows the context they are using the number in, so they can decide how to handle the exception.

A couple of rules:

• Never completely ignore an exception (OK, maybe InterruptedException). If you write try { ... } catch (Exception e) {} the empty catch clause will make it hard to spot why your code doesn't work.
• When you wrap an exception, always include the original exception as the cause.