예외를 스택 맨 위로 버블 링하는 것이 좋습니까?

Question

모든 메소드에서 예외를 포착하는 대신 예외를 버블 상에 놓아도 괜찮습니까? 어떤 경우에도해야합니까? .. 이 접근법에 미묘한 문제 나 부작용이 있습니까 (예 : 예외 세부 정보 손실, 스택 추적 또는 내부 예외 세부 정보 등)?

을 나는 WCF 기존 WSE3 웹 서비스를 이동하고 그래서 Y 클라이언트가 WSE3 클라이언트입니다 : 내 질문이 일반적이지만 다음과 같이

---

는, 현재 내 경우의 시나리오입니다.

FaultException이 WCF 서비스에서 발생할 때마다 클라이언트 측에 전달되도록 동작을 추가했습니다. OperationContract 메서드에서 예외가 발생하면 아무 문제없이 클라이언트 쪽에서 예외 메시지가 나타납니다. 그러나 OperationContract 이외의 메소드에서 발생할 때마다 어떻게 든 보안 관련 문제가 발생합니다. 나는 정확한 원인을 밝힐 수 없다.

그러나 나는 주위의 작업으로 예외를 OperationContract에서만 던지고 OperationContract까지 예외를 발생시키는 것으로 생각했습니다.

Answer 1

물론, 그것이 바로 그 때문입니다. 엄지 손가락의 규칙은 계속해서 합리적인 시도를 할 수있는 예외를 잡는 것입니다. 따라서 메모리가 부족한 경우 프로그램을 종료하고 종료하십시오. 많은 데이터를 반복하면서 0으로 나누면 다음 데이터로 넘어갈 수 있습니다.

업데이트

질문에 대한 응답은, 아니, (예외가 발생한 스택 추적을 포함한) 모든 세부 사항은 예외 객체로 전파됩니다.

당신이 가끔 볼 것은

highLevelFunction(){ 
    try { 
    lowerLevelFunction(); 
    } catch (LowLevelException e){ 
    throw HighLevelException(e); 
    } 
} 

또는 예외가 체인 같은 것입니다. "제로로 나누기"와 같은 저레벨 예외가 있습니다. 이를 catch하고 highLevelFunction이라는 루틴에 더 의미있는 "데이터 예외"와 같은 새로운 예외를 발생시킵니다.

Answer 2

는 최대 예외 거품을하자 대신 모든 방법을 잡기 위해 확인 (이, 나는 훨씬 최근 작성하지 않았습니다. 완벽한 C의 # 구문이 아닌 경우 PS 용서)?

는모든 방법으로하지 캐치 excpetions를 수행하십시오! - 당신은 예를 들어, 유용 뭔가를 할 수 있다면 당신은 만 적 예외를 포착해야합니다

• 핸들이 (즉,
• 내가 모든 nethod이 try-catch 블록을 둘러싸 된 응용 프로그램을 유지 한

몇 가지 중요한 상황에 맞는 정보를 추가)을 다시 던진다, 그리고 말 그대로 마다 방법을 의미하지 : 잡기

public void DoSomething() 
{ 
    try 
    { 
     throw new NotImplementedException(); 
    } 
    catch (Exception ex) 
    { 
     throw ExceptionHandler.CreateException(ex, "DoSomething"); 
    } 
} 

을 이와 같은 예외는 완전히 무의미하며 코드를 읽기 어렵게 만들고 예외를 추적하기 어렵게 만드는 것을 제외하고는 아무 것도하지 않습니다.

예를 들어 예외가 WCF 서비스와 같은 일부 프로세스 경계를 ​​통과해야하는 경우 예외가 세계에 노출되는 지점에서 먼저 예외를 기록하고 예외를 다시 게시하려는 경우가 있습니다. IPC 경계에 대한 호환 가능한 형식으로 서버의 모든 오류에 대한 로그를 얻을 수 있습니다.

그러나 많은 경우에이 목적을 위해 설계된 대체 메커니즘이 있습니다. WCF는 IErrorHandler 인터페이스를 사용하여 노출 된 각 메서드에서 try-catch 블록을 사용하지 않고 모든 처리되지 않은 예외를 일관된 방식으로 기록합니다.

Answer 3

전체 응용 프로그램 (GUI, 비즈니스, 데이터)이있는 경우 UI에서 거품을 만들어 이벤트에서 처리하십시오. 이렇게하면 동시에 사용자에게 메시지를 표시 할 수 있습니다. 또한 액션 출발점 (즉, 사용자가 액션 X를했을 때)을 잡았습니다. 어쨌든 원본을 찾기 위해 stacktrace를 로그 할 수 있기 때문에 모든 메소드에서 그것을 잡는 것은 CPU 집중적이고 불필요합니다. 미들웨어 응용 프로그램을 만들고 있다면 인터페이스에서 처리하거나 거품을 발생 시키십시오. 미들웨어 사용 방법에 따라 달라집니다.