일반적인 예외를 잡는 것이 실제로 나쁜 일입니까?

나는 일반적으로 대부분의 코드 분석 경고에 동의하며이를 준수하려고합니다. 그러나 나는 이것으로 어려움을 겪고있다.

CA1031 : 일반 예외 유형을 포착하지 마십시오

이 규칙의 근거를 이해합니다. 그러나 실제로 예외 발생에 관계없이 동일한 조치를 취하려면 왜 각각을 구체적으로 처리해야합니까? 또한 특정 예외를 처리하는 경우 나중에 호출하는 코드가 변경되어 새로운 예외가 발생하면 어떻게됩니까? 이제 새 예외를 처리하기 위해 코드를 변경해야합니다. 반면에 단순히 Exception코드 를 잡았다면 변경할 필요가 없습니다.

예를 들어, Foo가 Bar를 호출하고 Foo가 Bar에서 발생한 예외 유형에 관계없이 처리를 중지해야하는 경우, 내가 잡는 예외 유형에 대해 구체적으로 지정하면 어떤 이점이 있습니까?

아마도 더 좋은 예일 것입니다.

public void Foo()
{
    // Some logic here.
    LogUtility.Log("some message");
}

public static void Log()
{
    try
    {
        // Actual logging here.
    }
    catch (Exception ex)
    {
        // Eat it. Logging failures shouldn't stop us from processing.
    }
}

여기서 일반적인 예외를 잡지 않으면 가능한 모든 유형의 예외를 잡아야합니다. 패트릭은 OutOfMemoryException이런 식으로 다루어서는 안된다는 좋은 지적 이 있습니다. 모든 예외를 무시하고 싶다면 어떻게해야 OutOfMemoryException합니까?

이러한 규칙은 일반적 으로 좋은 아이디어이므로 따라야합니다.

그러나 이것이 일반적인 규칙임을 기억하십시오. 모든 상황을 다루지는 않습니다. 가장 일반적인 상황을 다룹니다. 특정 상황이 있고 기술이 더 낫다는 주장을 할 수 있다면 (그리고 코드에 주석을 작성하여 주장을 분명히 할 수 있어야합니다) 그렇게 한 다음 동료 검토를 받으십시오.

논쟁의 반대편.

위의 예가 그렇게하기에 좋은 상황이라고 생각하지 않습니다. 로깅 시스템이 실패하면 (아마도 다른 예외를 기록하고 있음) 응용 프로그램을 계속하고 싶지 않을 것입니다. 사용자가 무슨 일이 있었는지 볼 수 있도록 예외를 출력으로 출력하고 인쇄하십시오.

예, 일반적인 예외를 잡는 것은 나쁜 일입니다. 일반적으로 예외는 프로그램이 요청한 작업을 수행 할 수 없음을 의미합니다.

처리 할 수 있는 몇 가지 유형의 예외 가 있습니다.

• 치명적인 예외 : 메모리 부족, 스택 오버플로 등 일부 초자연적 힘이 당신의 우주를 망쳐 놓았으며 프로세스는 이미 죽어 가고 있습니다. 상황을 더 좋게 만들 수 없으므로 포기하십시오.
• 사용중인 코드의 버그로 인해 예외가 발생 했습니다. 처리하려고하지 말고 문제의 원인을 수정하십시오. 흐름 제어에 예외를 사용하지 마십시오
• 예외 상황 :이 경우에만 예외를 처리하십시오. 여기에는 네트워크 케이블 분리, 인터넷 연결 작동 중지, 권한 누락 등이 포함됩니다.

아, 그리고 일반적으로 : 예외를 잡으면 어떻게 해야할지 모른다면 빨리 실패하는 것이 좋습니다 (호출자에게 예외를 전달하고 처리하도록하십시오)

맨 위 바깥 쪽 고리에는 가능한 한 모든 것을 인쇄하기 위해 이들 중 하나가 있어야하며, 끔찍하고 폭력적이며 시끄러운 죽음으로 사망해야합니다 (이러한 일이 발생하지 않아야하며 누군가가들을 필요가 있음).

그렇지 않으면 이 위치에서 발생할 수있는 모든 것을 예상 하지 못했을 때 일반적으로 매우주의해야 하므로 올바르게 처리하지 않을 것입니다. 가능한 한 구체적으로 말해서 당신 이 일어날 것으로 알고 있는 사람들 만 잡으십시오 .

나쁜 것이 아니라 특정 캐치가 더 나을뿐입니다. 구체적으로 말하자면, 실제로 애플리케이션이 수행하는 작업을보다 구체적으로 이해하고 더 잘 제어 할 수 있음을 의미합니다. 일반적으로 예외를 잡아서 기록하고 계속하는 상황이 발생하면 어쨌든 나쁜 일이 발생할 수 있습니다. 코드 블록이나 메서드에서 발생할 수있는 예외를 구체적으로 파악하는 경우 로깅과 최선을 기대하는 대신 실제로 복구 할 가능성이 더 높습니다 .

두 가지 가능성은 상호 배타적이지 않습니다.

이상적인 상황에서는 메소드가 생성 할 수있는 가능한 모든 유형의 예외를 포착하고 예외별로 처리하며 결국에는 catch미래의 미지의 예외를 포착하기 위한 일반 조항을 추가해야합니다 . 이렇게하면 두 세계를 모두 활용할 수 있습니다.

try
{
    this.Foo();
}
catch (BarException ex)
{
    Console.WriteLine("Foo has barred!");
}
catch (BazException ex)
{
    Console.WriteLine("Foo has bazzed!");
}
catch (Exception ex)
{
    Console.WriteLine("Unknown exception on Foo!");
    throw;
}

보다 구체적인 예외를 잡으려면 먼저 예외를 두어야합니다.

편집 : 의견에 언급 된 이유로 마지막 캐치에 다시 던졌습니다.

나는 최근에 똑같이 숙고 해 왔으며 잠정적 인 결론은 .NET 예외 계층 구조 가 심각하게 엉망 이기 때문에 단순한 질문이 발생한다는 것입니다.

예를 들어, 낮은 가지고 있습니다 당신은 예외에 대한 합리적인 후보가 될 하지 않는 것이 있기 때문에, 할려구을 경향 코드가 아닌 합법적 인 런타임 오류 버그를 나타냅니다. 아. 넵. 그렇게 그 제외하고, 에서 파생 않습니다 직접, 그래서 당신은 잡기 (또는 잡을되지 않음)에 모든 "논리적 오류"를 배치 할 수없는 버킷가 없습니다.ArgumentNullExceptionNullReferenceExceptionNullReferenceExceptionSystemException

그런 다음 IMNSHO가 중요한 데 서투른 SEHException(를 통해 파생 ExternalException) SystemException따라서이 "정상적인"만들SystemException 당신이 얻을 때SEHException, 당신은 덤프를 작성하고 당신이 할 수있는 한 빨리 종료 할 - .NET 4에서 시작하여 적어도 일부 SEH 예외는발견되지 않은 손상된 상태 예외 로 간주됩니다. 좋은 점과CA1031규칙을 더욱 쓸모 없게만드는 사실은이제 게으른 사람들catch (Exception)이 어쨌든 이러한 최악의 유형을 잡을수 없기 때문입니다.

그런 다음 다른 Framework 항목이 Exception직접 또는 via를 일관성없이 파생하여 SystemExceptioncatch-clauses를 심각도 무트와 같은 그룹으로 그룹화하려고 시도합니다.

Vexing ExceptionC# 이라는 명성의 Lippert 씨의 작품이 있는데 , 그는 예외를 유용하게 분류 할 수 있습니다 C#. .NET의 언어와 디자인을 제외하고는 "외인성"인 것만 잡기를 원할 수 있습니다. 프레임 워크 예외는 간결한 방식으로 "외인적인 것만 잡을"수 없다. _{(그리고, 예를 들면,는 OutOfMemoryException수 아주 잘 든 큰 버퍼를 할당 할 수있는 API에 대한 완전히 정상 복구 가능한 오류 수)}

나를 위해 결론은,이다 방법 C#catch 블록이 작동하고 프레임 워크 예외 계층 구조를 설계하는 방법, 규칙이 CA1031완전히 쓸모 이상입니다 . 그것은 척 "예외를 삼키지 않는다"하지만 예외를 삼켜야하지만 당신은 무엇에, 당신이 잡을 것을 함께 할 수있는 제로가의 근본 문제를 돕기 위해 다음 을 수행하십시오

있다 적어도 4 가지 방법으로 합법적으로 잡은 처리하기는 Exception, 그리고 CA1031표면적으로 그들 중 하나 (즉 다시 던져 경우)를 처리 할 것으로 보인다.

사이드 참고로,라고하는 C # 6 기능 거기에 예외 필터 할 것입니다 CA1031제대로, 제대로, 제대로 캐치 예외를 필터링 할 수있을 것입니다 그 이후 다시 약간 더 유효하고, 필터링되지 않은 쓰기 적은 이유가이 catch (Exception).

포켓몬 예외 처리 (모두 잡아야합니다!)가 항상 나쁜 것은 아닙니다. 메서드를 클라이언트, 특히 최종 사용자에게 노출시킬 때 응용 프로그램이 중단되거나 타는 것보다 무엇이든 모든 것을 잡는 것이 좋습니다.

일반적으로 가능한 한 피해야합니다. 예외 유형에 따라 특정 조치를 취할 수 없다면 예외를 처리하지 않는 것이 좋으며 예외를 버블 링하는 대신 예외를 삼키거나 잘못 처리 할 수 ​​있습니다.

더 많은 독서 를 위해이 SO 답변을 살펴보십시오 .

프로그램을 정의되지 않은 상태로두기 때문에 일반적인 예외를 잡는 것은 좋지 않습니다. 문제가 발생한 곳을 모르므로 프로그램이 실제로 수행 한 작업이나 수행하지 않은 작업을 알 수 없습니다.

모든 것을 잡을 수있는 곳은 프로그램을 닫을 때입니다. 당신이 그것을 깨끗하게 정리할 수있는 한. 닫는 프로그램만큼 성가신 것은 없습니다. 오류 대화 상자 만 있으면 아무 것도 할 수없는 오류 대화 상자가 나타나고 컴퓨터가 종료되지 않습니다.

분산 환경에서 로그 방법은 역효과를 일으킬 수 있습니다. 일반적인 예외를 발견하면 다른 사용자가 로그를 작성하지 못하도록 프로그램이 여전히 로그 파일에 대한 잠금을 보유하고 있음을 의미 할 수 있습니다.

이 규칙의 근거를 이해합니다. 그러나 실제로 예외 발생에 관계없이 동일한 조치를 취하려면 왜 각각을 구체적으로 처리해야합니까?

다른 사람들이 말했듯이, 예외가 발생했는지에 관계없이 취해야 할 행동을 상상하는 것은 정말 어렵습니다 (불가능하지는 않지만). 그냥 하나의 예는 프로그램의 상태가 손상된 상황이다 어떤 추가 처리가 문제가 발생할 수 있습니다 (이 뒤에 이론적 근거이다 Environment.FailFast).

또한 특정 예외를 처리하는 경우 나중에 호출하는 코드가 변경되어 새로운 예외가 발생하면 어떻게됩니까? 이제 새 예외를 처리하기 위해 코드를 변경해야합니다. 반면 단순히 예외를 잡으면 내 코드를 변경할 필요가 없습니다.

취미 코드의 경우 포착하는 Exception것이 좋지만 전문가 급 코드의 경우 새로운 예외 유형을 도입하는 경우 메소드 서명의 변경과 동일한 방식으로 처리해야합니다. 즉, 주요 변경으로 간주됩니다. 이 관점에 가입하면 클라이언트 코드를 변경 (또는 검증)하는 것이 유일한 올바른 행동 과정이라는 것을 즉시 알 수 있습니다.

예를 들어, Foo가 Bar를 호출하고 Foo가 Bar에서 발생한 예외 유형에 관계없이 처리를 중지해야하는 경우, 내가 잡는 예외 유형에 대해 구체적으로 지정하면 어떤 이점이 있습니까?

물론, 예외가 발생하지 않기 때문 Bar입니다. Bar호출 스택에있는 시간 동안 Bar의 클라이언트 또는 런타임이 발생할 수있는 예외도 있습니다 . 잘 작성된 사람 Bar은 필요한 경우 호출자가 자체적으로 생성 한 예외를 구체적으로 잡을 수 있도록 필요한 경우 자체 예외 유형을 정의해야합니다.

OutOfMemoryException을 제외한 모든 예외를 무시하려면 어떻게해야합니까?

IMHO 이것은 예외 처리에 대해 잘못 생각하는 방법입니다. 블랙리스트가 아닌 화이트리스트 (캐치 예외 유형 A 및 B)에서 작동해야합니다 (X를 제외한 모든 예외를 캐치).

아마 . 모든 규칙에는 예외가 있으며 규칙을 엄격하게 준수해서는 안됩니다. 예를 들어 모든 예외를 삼키는 것이 합당한 사례 중 하나 일 수 있습니다. 예를 들어 중요한 프로덕션 시스템에 추적을 추가하려는 경우 변경 사항이 앱의 주요 작업을 방해하지 않는지 확인하려는 경우.

그러나 모든 실패를 자동으로 무시하기로 결정하기 전에 가능한 실패 원인에 대해 신중하게 고려해야합니다. 예를 들어, 예외의 이유가 다음과 같은 경우 :

• 로깅 메소드의 프로그래밍 오류로 인해 항상 특정 예외가 발생 함
• 구성에서 로깅 파일의 유효하지 않은 경로
• 디스크가 꽉 찼습니다

이 문제가 있음을 즉시 알리고 싶지 않아서 고칠 수 있습니까? 예외를 삼키는 것은 무언가 잘못되었다는 것을 결코 알지 못한다는 것을 의미합니다.

디스크가 가득 찬 것과 같은 일부 문제로 인해 응용 프로그램의 다른 부분도 실패 할 수 있습니다. 그러나이 실패는 지금 기록되지 않으므로 알 수 없습니다!

기술적 관점이 아닌 논리적 관점에서이 문제를 해결하고 싶습니다.

이제 새 예외를 처리하기 위해 코드를 변경해야합니다.

글쎄, 누군가가 그것을 처리해야 할 것입니다. 그것이 아이디어입니다. 라이브러리 코드 작성자는 새 예외 유형을 추가하는 데 신중해야하지만 클라이언트를 중단시킬 가능성이 높기 때문에이 문제가 자주 발생해서는 안됩니다.

귀하의 질문은 기본적으로 "무엇이 잘못되었는지 신경 쓰지 않는다면 어떻게됩니까? 나는 그것이 무엇인지 알아내는 번거 로움을 거쳐야합니까?"

여기에 아름다움 부분이 있습니다 : 아닙니다.

"따라서 다른 방법으로 볼 때 카펫 아래에 불쾌한 일이 자동으로 튀어 나와서 처리 될 수 있습니까?"

아니요, 그것이 작동하는 방식이 아닙니다.

요점은 가능한 예외 모음이 항상 예상 한 모음보다 크며 지역의 작은 문제와 관련하여 관심이 있다는 것입니다. 예상 한 것을 처리하고 예상치 못한 일이 발생하면이를 삼키기보다는 상위 레벨 처리기에 맡기십시오. 예상치 못한 예외에 신경 쓰지 않으면 호출 스택에 누군가가 내기를 걸고 예외가 처리기에 도달하기 전에 종료하는 것은 방해가 될 것입니다.

"하지만 ...하지만 ... 내가 신경 쓰지 않는 다른 예외 중 하나가 내 작업을 실패로 만들 수 있습니다!"

예. 그러나 현지에서 처리하는 것보다 항상 더 중요합니다. 화재 경보 나 상사처럼 당신이하고있는 일을 멈추고 더 시급한 일을하도록 지시합니다.

모든 프로세스의 최상위 수준에서 일반적인 예외를 파악하고 가능한 한 버그를보고 한 다음 프로세스를 종료하여 처리해야합니다.

일반적인 예외를 포착하지 말고 계속 실행하십시오.