2013-09-06 1 views
1

내가 아는 한, 첫 번째 예외가 발생하면 디버거에 알리고 (있는 경우), 여전히 처리되지 않은 경우 시스템은 스택에서 예외 처리기를 기반으로 가장 가까운 프레임을 검색합니다.C#에서 Vectored Strctured 예외 처리를 수행 할 수 있습니까?

벡터 처리 예외 처리에 대해 알게되었을 때 this link을 읽었습니다.

질문 1) 내가 관리 코드에서이를 수행 할 수있는 방법이 있는지 궁금합니다.

Question2) 나는 어떤 try{}catch{}는 프레임 기반의 핸들러이라고 생각하지만 우리는 이러한 무엇

AppDomain.CurrentDomain.UnhandledException += (x, y) => 
{ 
    Console.WriteLine("Unhandled exception"); 
}; 

같은 특정 이벤트에 핸들을 등록 할 때 어떻게됩니까?

+0

'UnhandledException' 이벤트는 정상적인 이벤트 일뿐입니다. 처리되지 않은 예외가 발생할 때 .NET에서 해당 이벤트를 발생시키기 때문에 예외 처리에만 관련됩니다. –

+0

@JohnSaunders 그래서 어떤 방식으로 clr이 try 블록 내에서 뭔가 잘못되었을 때 RaiseException 메서드를 호출하지 않는다는 것을 의미합니까? –

+0

clr이 방출하는 코드는 무엇입니까? 당신은'+ = (x, y) => 무엇이든간에 '을 의미합니까? 권리. 이것은 표준 이벤트 처리 코드 일뿐입니다. 특별한 것은 없습니다. .NET에는 특별한 기능이 거의 없습니다. –

답변

0

디버거는 첨부 된 경우에만 예외를 알립니다. 예를 들어 Visal Studio에서 디버깅하는 경우 먼저 호출되고 예외가 전달되면 예외 처리기가 호출됩니다. 모든 예외에서 디버거를 중지하려면 Visual Studio에서 디버그 메뉴를 선택하고 예외를 선택한 다음 디버거가 중단되도록 할 예외를 선택합니다. 이러한 핸들러가 없거나 핸들러가없는 경우 디버거는 실행을 중지하고 예외가 발생했음을 나타내는 일반 메시지를 표시하기 위해 두 번째 호출됩니다. 반면에 디버거가 연결되어 있지 않으면 모든 관리되는 프로덕션 코드의 99 % +에 해당하는 경우 디버거에 알리지 않습니다.

벡터 예외 처리는 비 관리 코드 (예 : C++)에서 사용하기위한 낮은 수준의 API입니다. 관리 코드 (C#)에서 가장 먼저 선택한 것은 try/catch/finally 블록과 함께 구조화 된 예외 처리를 사용해야합니다. C#과 같은 언어를 사용하는 대부분의 (99 % 이상) 관리 코드 개발자는 구조화 된 예외 처리가 적절하다는 것을 알았습니다.

여전히이 API를 사용해야하는 경우 P/Invoke를 사용하여 AddVectoredExceptionHandler를 호출해야합니다. 관리되지 않는 코드를 관리 코드에서 호출 할 수있는 한 가지 방법입니다. 두 가지주의 사항이 있습니다. 일반적인 overview에 대해서는이 링크를 참조하십시오. Mike Stall's blog은 관리되는 코드에서 벡터화 된 예외를 피할 것을 제안합니다. this thread에서 Mike Stall은 관리되지 않는 벡터 예외 처리기가 관리되는 코드로 다시 호출해서는 안됩니다. 또한 관리 예외는 벡터 처리 예외 처리에서 문서화되지 않은 기능이며 MS가 향후 CLR 릴리스에서 지원을 제거 할 수 있으므로 자신의 위험을 감수 할 것을 제안합니다.

AppDomain.UnhandledException event은 다른 핸들러가없는 경우에만 호출됩니다. 처리되지 않은 예외에 대한 정보를 기록하려는 상황에서 사용할 수 있지만 기존 코드의 큰 기본 구조에 적절한 구조적 예외 처리를 적용 할 시간이 거의 없거나 코드에 대한 액세스 권한이없는 것일 수 있습니다 그것은 예외를 던지고있다. 그렇지 않으면 try/catch/finally 블록을 대신 사용해야합니다.

첫 번째 예외 처리기가 호출되기 전에 발생하는 AppDomain.FirstChanceException event을 살펴볼 수도 있습니다. 이 기능은 액세스 권한이없는 다른 사람의 코드에 던져진 특정 예외에 대한 정보를 기록하기 만하면 유용 할 수 있습니다. 그것은 단지 통지이지만 예외 핸들러는 아닙니다. 이전에는 사용 해 본 적이 없으므로 성능에 어느 정도 영향을 미칠지 모릅니다. 내 관심사는 여기에 Microsoft 개발자가 때때로 실제 오류 이외의 여러 가지 CLR 예외를 throw하는 것입니다. 이 동작을 보려면 CLR 런타임 예외를 포함하여 모든 예외를 중단하도록 디버거를 설정하십시오. 이 작업은 Visual Studio의 디버그 메뉴에서 예외를 선택하여 수행 할 수 있습니다.따라서 모든 CLR 예외가이 이벤트를 발생시킬 가능성이 높기 때문에 실적에 미치는 영향이 어느 정도인지는 알 수 없습니다. 공정하게하기 위해 내가 마지막으로 한 것은 VS 2008이었습니다. 이는 CLR의 이후 버전에서 사실이 아닐 수도 있습니다. 나는이 사건이 발사 할 예외를 제한 할 방법을 찾지 못한다. 따라서 관심이없는 예외를 필터링하고 성능에 미치는 영향을 알아보기 위해 실험해야합니다.

관련 문제