이것은 나쁜 생각입니다. 사실, 잡는 Exception것 조차도 일반적으로 나쁜 생각입니다. 예를 들어 보겠습니다.

try {
    inputNumber = NumberFormat.getInstance().formatNumber( getUserInput() );
} catch(Throwable e) {
    inputNumber = 10; //Default, user did not enter valid number
}

이제 getUserInput ()이 잠시 차단되고 다른 스레드가 최악의 방법으로 스레드를 중지한다고 가정 해 보겠습니다 (thread.stop () 호출). catch 블록은 ThreadDeath오류 를 포착합니다 . 이것은 매우 나쁩니다. 해당 예외를 포착 한 후 코드의 동작은 거의 정의되지 않았습니다.

예외를 잡는 것과 비슷한 문제가 발생합니다. 아마도getUserInput() 때문에 InterruptException의 실패, 또는 결과, 또는 다른 실패의 모든 종류를 기록하는 동안 권한은 예외를 부인했다. 그 때문에 문제를 해결하는 방법도 모르기 때문에 무엇이 잘못되었는지 전혀 모릅니다.

세 가지 더 나은 옵션이 있습니다.

1-처리 방법을 알고있는 예외를 정확히 포착합니다.

try {
    inputNumber = NumberFormat.getInstance().formatNumber( getUserInput() );
} catch(ParseException e) {
    inputNumber = 10; //Default, user did not enter valid number
}

2-발생하고 처리 방법을 모르는 예외를 다시 발생시킵니다.

try {
    doSomethingMysterious();
} catch(Exception e) {
    log.error("Oh man, something bad and mysterious happened",e);
    throw e;
}

3-finally 블록을 사용하면 다시 던지는 것을 기억할 필요가 없습니다.

 Resources r = null;
 try {
      r = allocateSomeResources();
      doSomething(r);
 } finally {
     if(r!=null) cleanUpResources(r);
 }

답변

try {
   ...
} catch (RuntimeException exception) {
  //do something
} catch (Error error) {
  //do something
}

 * An <code>Error</code> is a subclass of <code>Throwable</code>
 * that indicates serious problems that a reasonable application
 * should not try to catch. Most such errors are abnormal conditions.
 * The <code>ThreadDeath</code> error, though a "normal" condition,
 * is also a subclass of <code>Error</code> because most applications
 * should not try to catch it.

 * A method is not required to declare in its <code>throws</code>
 * clause any subclasses of <code>Error</code> that might be thrown
 * during the execution of the method but not caught, since these
 * errors are abnormal conditions that should never occur.
 *
 * @author  Frank Yellin
 * @version %I%, %G%
 * @see     java.lang.ThreadDeath
 * @since   JDK1.0