2010-08-18 2 views
13

문제가있는 경우 DOS errorlevel을 0이 아닌 값으로 설정해야하는 단일 스레드 응용 프로그램이 있습니다. RuntimeException을 던지거나 System.exit (0이 아닌)을 사용하는 것이 더 좋습니까? 스택 트레이스가 필요 없으며이 앱이 확장/재사용 될 것으로 기대하지 않습니다. 이 두 옵션의 차이점은 무엇입니까?System.exit (num) 또는 Maintime에서 RuntimeException을 throw합니까?

+1

질문에 대한 답변을 얻은 것 같습니다. DOS 오류 코드를 설정해야한다면 System.exit (코드)를 사용해야합니다. 예외가 있으면 그렇게 할 수 없습니다. – EJP

+0

주에서 RuntimeException을 Thowing하면 errorlevel을 3으로 설정합니다. 이유가 확실하지 않거나 모든 상황에 해당하는지는 확실하지 않습니다. – VarV

답변

9

예외적 인 조건이없는 한 예외를 발생시키지 마십시오. System.exit(int) 정확히 거기 때문입니다. 그걸 써.

편집 : 질문을 잘못 읽었을 수 있습니다. 나는 당신이 예외적으로 던지거나 System.exit을 사용하는 것이 더 나은지 여부에 관계없이 JVM을 정상적으로 종료하지만 무언가가 제대로되지 않았다는 신호를 보내고 싶을 때 묻고 있다고 생각했습니다.

그러나 발생한 문제가 Java 예외로 이미 표시된 경우 예외를 처리하지 않도록하는 것이 좋습니다. 예외를 잡을 필요가 없으며 System.exit으로 전화하십시오.

자신의 예외를 던질 것인지 또는 System.exit을 호출 할 것인지 결정할 수있는 경우 오류 상태가 메소드를 호출하는 Java 코드에 의해 처리 될 수있는 것인지 생각해보십시오. main 메서드에서 직접 오류가 발생하면 예외를 처리 할 호출자가 없을 가능성이 있으므로 System.exit을 호출해야합니다. 그렇지 않으면 일반적으로 예외를 throw하는 것이 가장 좋습니다. 그러나 RuntimeException이 아닌 경우에는 발생한 오류를 적절하게 나타내는 예외 유형을 사용해야합니다. 필요한 경우 RuntimeException의 고유 서브 클래스를 작성하십시오.

+0

그러면 main에서 던져진 예외가 errorlevel을 설정하는 이유는 무엇입니까? 그들이 어떤 이유로 든 거기에있는 것 같습니다. – VarV

+2

응용 프로그램이 성공적으로 완료되지 않으면 반환 코드는 0이 아니어야합니다. 처리되지 않은 예외가 있으면 JVM이 자동으로 반환 코드를 1로 설정하여 부모 프로세스가 오류가 발생했습니다. –

-4

System.exit() 권장하지 않습니다. JVM을 종료합니다.

+0

이 경우 JVM을 종료하면 오류가 발생해도 응용 프로그램이 종료됩니다. – VarV

+0

generic RuntimeException도 제 생각에 –

+0

system.exit (int) 또는 새로운 RuntimeException을 던지지 말고 후자가 일반적인 RuntimeException으로 간주되지 않습니까? – VarV

6

일반적으로이 상황에서 나는 주 방법으로 모든 예외를 처리 할 것이며 아마도 System.exit을 호출 할 것입니다. 이로써 예외 조건을 처리하는 위치/방법/방법에 대한 유연성을 제공하면서도 오류 코드로 종료해야 할 필요성을 충족시킵니다. 특히 리턴 코드와 사용자가 생성 할 수있는 기타 출력 (오류 메시지, 스택 추적 등)을 제어 할 수 있습니다. main에 예외를 던지거나 예외를 벗어나면 그 제어권을 잃게됩니다.

는 최상위 예외 핸들러에서 System.exit 전화, 요약하면 :

static public void main() { 
    try { 
     runMyApp(); 
    } catch (Exception e) { 
     System.exit(1); 
    } 
} 
+0

아마도이 솔루션을 사용할 것입니다. 그러나 System.exit이 main에서 예외를 throw하는 것보다 선호되는 이유에 대해 알아 보았습니다. – VarV

3

을 System.exit를 스택 트레이스를 출력합니다, 당신은 것을 필요하지 않은 경우, 사용 말아야 던져 예외 .

종료하면 Sytem.out을 사용자에게 알릴 수 있습니다 (응용 프로그램이 commanline 환경에서만 실행되고 있다고 가정합니다).

오류를 별도의 로그에 기록하면 모든 오류를 포착 할 수 있으므로 터미널을 닫을 때 스택 추적이 영구적으로 손실되지 않습니다. 이 목적을 위해 log4j를 살펴보십시오. 정말 사용하기 쉽습니다.

+0

예, 명령 행 환경에만 있습니다. 스택 추적은 필요하지 않습니다. 빌드 과정에서 자동화 된 단계이기 때문에 log4j가 과도합니다. – VarV

+0

그런 다음 system.exit 솔루션을 찾으십시오. 나중에 특히 리턴 코드를 확인하는 것이 좋은 해결책입니다. 그렇게하면 다른 코드를 사용하여 잘못 된 것을 알리거나 System.exit (-1) – Jes

2

APP 자체는 System.exit을 사용해야합니다. 호출 환경 (스크립트)과의 인터페이스입니다. 물론 모든 내부 구성 요소는 Exception을 사용해야합니다. 당신이 함께 넣어 때이 될 수있는 두 조금은 저질렀 :

Application.main(...) { 
    parse(args); 
    check(...); 
    try { 
    MyObject o = ...; 
    o.doMyStuff(); 
    } catch (Exception e) { 
    System.err.println("Oops, something went wrong!"); // by example, or use a logging framework! // anyway in a shell app System.in/out/err IS my interface with the outworld 
    System.exit(ERROR_CODE); 
    } 
    System.out.println("Worked!"); 
} 
0

을 System.exit (NUM)는 자사의 종료 JVM으로, 좋은 옵션이 아닙니다 플러스도 마침내 당신이 후에있을 경우 차단하려면 실행 didnt는 블록을 잡아라.

RuntimeException도 옵션 중에서 가장 좋지 않을 수도 있습니다. 앞서 언급했듯이 하위 클래스는 특정 예외입니다. 내 의견으로는 더 나은 옵션 일 수 있습니다. - 멕시코어

관련 문제