시도 / 캐치 / 로그 / 다시 던지기-안티 패턴입니까?

중앙 위치 또는 프로세스 경계에서 예외 처리의 중요성이 try / catch 주위의 모든 코드 블록을 흩 뜨리지 않고 모범 사례로 강조된 여러 게시물을 볼 수 있습니다. 나는 대부분의 사람들이 그것의 중요성을 이해한다고 생각하지만 사람들은 여전히 ​​예외 상황에서 문제 해결을 쉽게하기 위해 더 많은 컨텍스트 특정 정보를 기록하기를 원하기 때문에 catch-log-rethrow 안티 패턴으로 끝나는 것을 볼 수 있습니다. 전달) 방법은 try / catch / log / rethrow 주위에 메소드를 래핑하는 것입니다.

public static bool DoOperation(int num1, int num2)
{
    try
    {
        /* do some work with num1 and num2 */
    }
    catch (Exception ex)
    {
        logger.log("error occured while number 1 = {num1} and number 2 = {num2}"); 
        throw;
    }
}

예외 처리 모범 사례를 계속 유지하면서 이것을 달성하는 올바른 방법이 있습니까? PostSharp와 같은 AOP 프레임 워크에 대해 들었지만 이러한 AOP 프레임 워크와 관련된 단점이나 주요 성능 비용이 있는지 알고 싶습니다.

감사!

문제는 로컬 catch 블록이 아니며 log 및 rethrow 입니다. 예외를 처리하거나 컨텍스트를 추가하고 새 예외를 추가하는 새 예외로 랩하십시오. 그렇지 않으면 동일한 예외에 대해 여러 개의 중복 로그 항목이 표시됩니다.

여기서 아이디어는 응용 프로그램을 디버깅하는 기능을 향상시키는 것입니다.

예 # 1 : 처리

try
{
    doSomething();
}
catch (Exception e)
{
    log.Info("Couldn't do something", e);
    doSomethingElse();
}

예외를 처리하는 경우 예외 로그 항목의 중요도를 쉽게 다운 그레이드 할 수 있으며 해당 예외를 체인으로 확장 할 이유가 없습니다. 이미 다루었습니다.

예외 처리에는 문제가 발생했음을 사용자에게 알리거나 이벤트를 기록하거나 단순히 무시하는 것이 포함될 수 있습니다.

참고 : 의도적으로 예외를 무시하는 경우 빈 catch 절에 이유를 명확하게 나타내는 주석을 제공하는 것이 좋습니다. 이것은 미래의 관리자에게 실수 나 게으른 프로그래밍이 아니라는 것을 알려줍니다. 예:

try
{
    context.DrawLine(x1,y1, x2,y2);
}
catch (OutOfMemoryException)
{
    // WinForms throws OutOfMemory if the figure you are attempting to
    // draw takes up less than one pixel (true story)
}

예제 # 2 : 추가 컨텍스트 추가 및 던지기

try
{
    doSomething(line);
}
catch (Exception e)
{
    throw new MyApplicationException(filename, line, e);
}

구문 분석 코드의 줄 번호 및 파일 이름과 같은 추가 컨텍스트를 추가하면 입력 파일을 디버깅하는 기능을 향상시키는 데 도움이 될 수 있습니다 (문제가 있다고 가정). 이것은 일종의 특별한 경우이므로 "ApplicationException"에서 예외를 다시 랩핑하여 브랜드를 변경하는 것만으로는 디버그에 도움이되지 않습니다. 추가 정보를 추가하십시오.

예 3 : 예외를 제외하고 아무 것도하지 마십시오

try
{
    doSomething();
}
finally
{
   // cleanup resources but let the exception percolate
}

이 마지막 경우, 예외를 건드리지 않고 그대로 두십시오. 가장 바깥 쪽 레이어의 예외 처리기는 로깅을 처리 할 수 ​​있습니다. 이 finally절은 메소드에 필요한 모든 자원을 정리하는 데 사용되지만 예외가 발생했다는 것을 기록하는 장소는 아닙니다.

로컬 캐치가 안티 패턴이라고 생각하지 않습니다. 실제로 올바르게 기억하면 실제로 Java로 적용됩니다!

오류 처리를 구현할 때 가장 중요한 것은 전체 전략입니다. 서비스 경계에서 모든 예외를 포착하는 필터를 원할 수도 있고 수동으로 예외를 가로 채기를 원할 수도 있습니다. 팀 전체의 코딩 표준에 해당하는 전체 전략이있는 한 둘 다 괜찮습니다.

개인적으로 나는 다음 중 하나를 수행 할 수있을 때 함수 내부에서 오류를 포착하고 싶습니다.

• 상황에 맞는 정보 추가 (예 : 객체 상태 또는 진행 상황)
• 예외를 안전하게 처리하십시오 (예 : TryX 메소드)
• 시스템이 서비스 경계를 ​​넘어 외부 라이브러리 또는 API를 호출 중입니다.
• 다른 유형의 예외를 포착하고 다시 던져야합니다 (아마도 원본을 내부 예외로 사용함)
• 일부 저가 백그라운드 기능의 일부로 예외가 발생했습니다.

이 경우 중 하나가 아닌 경우 로컬 try / catch를 추가하지 않습니다. 그렇다면 시나리오에 따라 예외 (예 : false를 반환하는 TryX 메서드)를 처리하거나 다시 던질 수 있으므로 전역 전략에 의해 예외가 처리됩니다.

예를 들면 다음과 같습니다.

public bool TryConnectToDatabase()
{
  try
  {
    this.ConnectToDatabase(_databaseType); // this method will throw if it fails to connect
    return true;
  }
  catch(Exception ex)
  {
     this.Logger.Error(ex, "There was an error connecting to the database, the databaseType was {0}", _databaseType);
    return false;
  }
}

또는 다시 던지는 예 :

public IDbConnection ConnectToDatabase()
{
  try
  {
    // connect to the database and return the connection, will throw if the connection cannot be made
  }
  catch(Exception ex)
  {
     this.Logger.Error(ex, "There was an error connecting to the database, the databaseType was {0}", _databaseType);
    throw;
  }
}

그런 다음 스택 상단의 오류를 포착하고 사용자에게 멋진 사용자 친화적 인 메시지를 제공합니다.

어떤 방법을 사용하든 항상이 시나리오에 대한 단위 테스트를 작성하는 것이 좋습니다. 따라서 기능이 변경되지 않고 나중에 프로젝트 흐름을 방해하지 않도록 할 수 있습니다.

현재 어떤 언어로 작업하고 있는지 언급하지 않았지만 .NET 개발자이며 언급하지 않는 것이 너무 많습니다.

쓰지 마세요:

catch(Exception ex)
{
  throw ex;
}

사용하다:

catch(Exception ex)
{
  throw;
}

전자는 스택 추적을 재설정하고 최상위 레벨 캐치를 전혀 쓸모 없게 만듭니다!

TLDR

로컬로 캐치는 것은 반 패턴이 아니며 종종 디자인의 일부일 수 있으며 오류에 컨텍스트를 추가하는 데 도움이 될 수 있습니다.

이것은 언어에 많이 의존합니다. 예를 들어 C ++은 예외 오류 메시지에 스택 추적을 제공하지 않으므로 잦은 catch-log-rethrow를 통해 예외를 추적하면 도움이 될 수 있습니다. 반대로 Java 및 유사한 언어는 매우 우수한 스택 추적을 제공하지만 이러한 스택 추적의 형식을 구성 할 수는 없습니다. 중요한 언어를 실제로 추가 할 수없는 경우 (예 : 저수준 SQL 예외를 비즈니스 로직 작업의 컨텍스트와 연결)를 제외하고 이러한 언어로 예외를 잡아서 다시 던지는 것은 의미가 없습니다.

리플렉션을 통해 구현되는 모든 오류 처리 전략은 언어에 내장 된 기능보다 거의 효율성이 떨어집니다. 또한 광범위한 로깅은 피할 수없는 성능 오버 헤드를 갖습니다. 따라서이 소프트웨어의 다른 요구 사항과 비교하여 얻은 정보 흐름의 균형을 맞출 필요가 있습니다. 즉, 컴파일러 수준 계측에 구축 된 PostSharp와 같은 솔루션은 일반적으로 런타임 리플렉션보다 훨씬 낫습니다.

나는 개인적으로 모든 것을 기록하는 것은 관련이없는 정보가 많이 포함되어 있기 때문에 도움이되지 않는다고 생각합니다. 따라서 자동화 된 솔루션에 회의적입니다. 좋은 로깅 프레임 워크가 주어지면 어떤 종류의 정보를 기록하고이 정보의 형식을 지정해야하는지에 대한 합의 된 코딩 지침을 마련하는 것으로 충분할 수 있습니다. 그런 다음 중요한 곳에 로깅을 추가 할 수 있습니다.

비즈니스 로직에 로그온하는 것이 유틸리티 기능에 로그온하는 것보다 훨씬 중요합니다. 또한 프로세스의 최상위 수준에서만 로깅이 필요한 실제 충돌 보고서의 스택 추적을 수집하면 로깅에서 가장 가치가 높은 코드 영역을 찾을 수 있습니다.

try/catch/log모든 방법에서 볼 때 개발자가 응용 프로그램에서 발생할 수있는 것과 그렇지 않은 것을 전혀 알지 못하고 최악의 상황을 가정했으며 예상되는 모든 버그로 인해 모든 곳을 선점 적으로 기록했습니다.

이것은 단위 및 통합 테스트가 불충분하고 개발자가 디버거에서 많은 코드를 단계별로 살펴 보는 데 익숙하며 많은 로깅을 통해 테스트 환경에서 버그가있는 코드를 배포하고 문제를 찾을 수 있기를 바랍니다. 로그.

예외를 발생 시키는 코드 는 예외를 잡아서 기록하는 중복 코드보다 유용 할 수 있습니다. 메소드가 예기치 않은 인수를 수신하고 서비스 경계에 기록 할 때 의미있는 메시지와 함께 예외를 발생시키는 경우, 유효하지 않은 인수의 부작용으로 발생한 예외를 즉시 기록하고 그 원인을 추측해야하는 것보다 훨씬 도움이됩니다. .

널이 예입니다. 인수 또는 메소드 호출의 결과로 값을 가져오고 널이 아니어야하는 경우 예외를 처리하십시오. NullReferenceException널 (NULL) 값으로 인해 나중에 던져진 5 줄 의 결과 만 기록하지 마십시오 . 어느 쪽이든 예외가 발생하지만 한 쪽은 무언가를 알려주고 다른 쪽은 무언가를 찾게합니다.

다른 사람들이 말했듯이 서비스 경계에서 또는 예외가 정상적으로 처리되어 예외가 다시 발생하지 않을 때마다 예외를 기록하는 것이 가장 좋습니다. 가장 중요한 차이점은 무언가와 아무것도 아닌 것입니다. 한 곳에서 예외가 기록되면 쉽게 찾을 수 있습니다. 필요할 때 필요한 정보를 찾을 수 있습니다.

아직 예외에없는 컨텍스트 정보를 기록해야하는 경우 새 예외로 랩핑하고 원래 예외를로 제공하십시오 InnerException. 이렇게하면 원래 스택 추적이 유지됩니다. 그래서:

public static bool DoOperation(int num1, int num2)
{
    try
    {
        /* do some work with num1 and num2 */
    }
    catch (Exception ex)
    {
        throw new Exception("error occured while number 1 = {num1} and number 2 = {num2}", ex);
    }
}

Exception생성자에 대한 두 번째 매개 변수 는 내부 예외를 제공합니다. 그런 다음 모든 예외를 한곳에 기록 할 수 있으며 여전히 동일한 로그 항목에 전체 스택 추적 및 상황에 맞는 정보를 얻을 수 있습니다 .

사용자 정의 예외 클래스를 사용할 수 있지만 요점은 동일합니다.

try / catch / log / rethrow는 혼란스러운 로그로 이어질 수 있기 때문에 혼란스러워집니다. 예를 들어 컨텍스트 정보를 기록하고 최상위 핸들러에서 실제 예외를 기록하는 사이에 다른 스레드에서 다른 예외가 발생하면 어떻게됩니까? 새 예외가 원본에 정보를 추가하는 경우 try / catch / throw는 괜찮습니다.

예외 자체는 메시지, 오류 코드 및 기타 정보를 포함하여 적절한 로깅에 필요한 모든 정보를 제공해야합니다. 따라서 예외를 다시 발생 시키거나 다른 예외를 throw하기 위해 예외를 포착 할 필요는 없습니다.

종종 DatabaseExceptionException, InvalidQueryException 및 InvalidSQLParameterException을 포착하고 DatabaseException을 다시 발생시키는 것과 같이 여러 예외 패턴이 포착되어 일반적인 예외로 다시 발생하는 것을 볼 수 있습니다. 그럼에도 불구하고, 나는이 모든 특정 예외가 먼저 DatabaseException에서 파생되어야한다고 주장하므로 다시 던질 필요가 없습니다.

불필요한 try catch 절 (순전히 로깅을위한 것)을 제거하면 실제로 작업이 더 쉬워지고 쉬워지지는 않습니다. 프로그램에서 예외를 처리하는 장소 만 예외를 기록해야하며, 프로그램을 정상적으로 종료하기 전에 예외를 기록하기위한 마지막 시도를위한 프로그램 전체 예외 처리기가 실패해야합니다. 예외에는 예외가 발생한 정확한 지점을 나타내는 전체 스택 추적이 있어야하므로 "컨텍스트"로깅을 제공 할 필요가없는 경우가 많습니다.

AOP는 일반적으로 약간의 속도 저하를 수반하지만 빠른 수정 솔루션 일 수 있습니다. 대신 값이 추가되지 않은 불필요한 try catch 절을 완전히 제거하는 것이 좋습니다.