C #에서 예외를 잡아서 다시 던지는 이유는 무엇입니까?

직렬화 가능한 DTO 에 대한 기사 C #-데이터 전송 개체 를보고 있습니다.

이 기사에는 다음 코드가 포함되어 있습니다.

public static string SerializeDTO(DTO dto) {
    try {
        XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
        StringWriter sWriter = new StringWriter();
        xmlSer.Serialize(sWriter, dto);
        return sWriter.ToString();
    }
    catch(Exception ex) {
        throw ex;
    }
}

이 기사의 나머지 부분은 제정신이며 합리적으로 보이지만 try-catch-throw는 WtfException을 발생시킵니다. 예외를 전혀 처리하지 않는 것과 정확히 같지 않습니까?

에르고 :

public static string SerializeDTO(DTO dto) {
    XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
    StringWriter sWriter = new StringWriter();
    xmlSer.Serialize(sWriter, dto);
    return sWriter.ToString();
}

아니면 C #의 오류 처리에 대한 근본적인 내용이 누락 되었습니까? Java와 거의 동일하지만 (확인 된 예외 제외) 그렇지 않습니까? ... 즉, 둘 다 C ++을 개선했습니다.

스택 오버플로 질문 매개 변수가없는 캐치를 다시 던지는 것과 아무것도하지 않는 것의 차이점은 무엇입니까? try-catch-throw가 절대 안된다는 내 주장을지지하는 것 같습니다.

편집하다:

미래 에이 스레드를 찾는 사람을 요약하면 ...

하지 마라

try {
    // Do stuff that might throw an exception
}
catch (Exception e) {
    throw e; // This destroys the strack trace information!
}

스택 추적 정보는 문제의 근본 원인을 식별하는 데 중요 할 수 있습니다!

하다

try {
    // Do stuff that might throw an exception
}
catch (SqlException e) {
    // Log it
    if (e.ErrorCode != NO_ROW_ERROR) { // filter out NoDataFound.
        // Do special cleanup, like maybe closing the "dirty" database connection.
        throw; // This preserves the stack trace
    }
}
catch (IOException e) {
    // Log it
    throw;
}
catch (Exception e) {
    // Log it
    throw new DAOException("Excrement occurred", e); // wrapped & chained exceptions (just like java).
}
finally {
    // Normal clean goes here (like closing open files).
}

Java와 같이 덜 구체적인 예외보다 더 구체적인 예외를 포착하십시오.

참고 문헌 :

• MSDN-예외 처리
• MSDN-try-catch (C # 참조)

먼저; 기사의 코드가 수행하는 방식은 사악합니다. throw ex이 throw 문이있는 지점으로 예외의 호출 스택을 재설정합니다. 예외가 실제로 생성 된 위치에 대한 정보가 손실됩니다.

둘째, 당신이 그렇게 잡아서 다시 던지면, 부가 가치가 없다는 것을 알 수 있습니다. 위의 코드 예제 throw ex는 try-catch 없이도 좋을 것입니다 (또는 비트가 더 좋았습니다).

그러나 예외를 잡아서 다시 던지는 경우가 있습니다. 로깅은 다음 중 하나 일 수 있습니다.

try 
{
    // code that may throw exceptions    
}
catch(Exception ex) 
{
    // add error logging here
    throw;
}

이러지 마

try 
{
...
}
catch(Exception ex)
{
   throw ex;
}

스택 추적 정보가 손실됩니다 ...

어느 쪽이든

try { ... }
catch { throw; }

또는

try { ... }
catch (Exception ex)
{
    throw new Exception("My Custom Error Message", ex);
}

다시 던져야 할 이유 중 하나는 예를 들어 다른 예외를 처리하는 경우입니다.

try
{
   ...
}
catch(SQLException sex)
{
   //Do Custom Logging 
   //Don't throw exception - swallow it here
}
catch(OtherException oex)
{
   //Do something else
   throw new WrappedException("Other Exception occured");
}
catch
{
   System.Diagnostics.Debug.WriteLine("Eeep! an error, not to worry, will be handled higher up the call stack");
   throw; //Chuck everything else back up the stack
}

C # (C # 6 이전)은 VB가 수행하는 CIL "필터링 된 예외"를 지원하지 않으므로 C # 1-5에서 예외를 다시 발생시키는 한 가지 이유는 catch () 시점에 충분한 정보가 없기 때문입니다. 실제로 예외를 잡을 것인지 결정합니다.

예를 들어 VB에서는

Try
 ..
Catch Ex As MyException When Ex.ErrorCode = 123
 .. 
End Try

... 다른 ErrorCode 값으로 MyException을 처리하지 않습니다. v6 이전의 C #에서는 ErrorCode가 123이 아닌 경우 MyException을 포착하고 다시 발생시켜야합니다.

try 
{
   ...
}
catch(MyException ex)
{
    if (ex.ErrorCode != 123) throw;
    ...
}

C # 6.0부터 VB와 마찬가지로 필터링 할 수 있습니다 .

try 
{
  // Do stuff
} 
catch (Exception e) when (e.ErrorCode == 123456) // filter
{
  // Handle, other exceptions will be left alone and bubble up
}

다음과 같은 코드를 사용하는 주요 이유는 다음과 같습니다.

try
{
    //Some code
}
catch (Exception e)
{
    throw;
}

캐치에 중단 점을 가질 수 있도록 인스턴스화 된 예외 객체가 있습니다. 개발 / 디버깅하는 동안 나는 이것을 많이한다. 물론 컴파일러는 사용되지 않은 모든 e에 대해 경고를 제공하며 이상적으로는 릴리스 빌드 전에 제거해야합니다.

그래도 디버깅하는 동안 좋습니다.

예외를 다시 던지는 유효한 이유는 예외에 정보를 추가하거나 원래 예외 중 하나를 원래 예외로 래핑하기 때문일 수 있습니다.

public static string SerializeDTO(DTO dto) {
  try {
      XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
      StringWriter sWriter = new StringWriter();
      xmlSer.Serialize(sWriter, dto);
      return sWriter.ToString();
  }
  catch(Exception ex) {
    string message = 
      String.Format("Something went wrong serializing DTO {0}", DTO);
    throw new MyLibraryException(message, ex);
  }
}

이것은 예외를 전혀 처리하지 않는 것과 정확히 같지 않습니까?

정확히는 같지 않습니다. 예외의 스택 추적을 재설정합니다. 나는 이것이 아마도 실수이므로 잘못된 코드의 예라는 것에 동의하지만.

당신은 ex를 던지고 싶지 않습니다-이것은 호출 스택을 잃을 것입니다. 예외 처리 (MSDN)를 참조하십시오 .

그리고 그렇습니다 .try ... catch는 유용한 정보를 제공하지 않습니다 (콜 스택을 잃어 버리는 것을 제외하고는-어떤 이유로 든이 정보를 노출시키지 않으려는 경우가 아니라면 실제로 더 나쁩니다).

사람들이 언급하지 않은 요점은 .NET 언어는 실제로 적절한 구별을하지 않지만 예외가 발생했을 때 조치 를 취해야 하는지 여부와 문제를 해결 할지 여부에 대한 질문은 실제로 다른 질문이라는 것입니다. 예외를 기반으로 조치를 취해야하는 경우가 많지만 해결하려는 희망이 없으며 예외를 "해결"하는 데 필요한 모든 것이 스택을 특정 지점으로 풀어야하는 경우가 있습니다. 추가 조치가 필요하지 않습니다. .

우리가 처리 할 수있는 것만을 "잡아야"한다는 공통된 지혜 때문에 예외가 발생했을 때 조치를 취해야하는 많은 코드는 그렇지 않습니다. 예를 들어, 많은 코드는 잠금을 획득하고 보호 된 객체를 "일시적으로"불변을 위반하는 상태로 만든 다음 객체를 합법적 인 상태로 놓은 다음 다른 사람이 객체를 볼 수 있기 전에 잠금을 해제합니다. 객체가 위험한 상태에있는 동안 예외가 발생하면 일반적으로 해당 상태에있는 객체와 잠금을 해제하는 것이 일반적입니다. 객체가 "위험한"조건에있는 동안 예외가 발생하면 잠금이 명시 적으로 무효화되므로 나중에 더 이상이를 획득하려는 시도는 즉시 실패합니다.

대부분의 .NET 언어에서 예외를 기반으로 코드를 처리하는 유일한 방법은 예외 catch를 해결하지 않을 것임을 알고 있지만 문제의 조치를 수행 한 다음 다시 수행하는 것 throw입니다. 어떤 예외가 발생했는지에 대해 코드가 신경 쓰지 않을 경우 가능한 또 다른 방법 ok은 try/finally블록 과 함께 플래그 를 사용하는 것입니다 . ok플래그를 false블록 true앞, 블록이 끝나기 전 및 블록 안에 있는 플래그 앞에 설정하십시오 return. 그런 다음에 설정되지 않은 finally경우 ok예외가 발생했다고 가정합니다 . 이러한 접근 방식은 catch/ 보다 의미 상 낫지 만, throw추악하고 유지 관리가 쉽지 않습니다.

라이브러리 또는 dll에 대한 프로그래밍 기능을 수행 할 때 유용 할 수 있습니다.

이 rethrow 구조는 의도적으로 호출 스택을 재설정하여 함수 내부의 개별 함수에서 발생한 예외를 보는 대신 함수 자체에서 예외를 가져 오는 데 사용할 수 있습니다.

나는 이것이 던져진 예외가 더 깨끗하고 라이브러리의 "루트"에 들어 가지 않도록 사용되었다고 생각합니다.

catch-throw를 발생시키는 한 가지 이유는 스택에서 필터링이 더 깊이 발생하는 예외 필터 ( random old link ) 를 비활성화하는 것 입니다. 그러나 물론 그것이 의도라면, 거기에 의견이있을 것입니다.

catch 블록에서 수행중인 작업과 호출 코드에 오류를 전달 하려는지 여부에 따라 다릅니다.

Catch io.FileNotFoundExeption ex대체 파일 경로 또는 이와 유사한 경로를 말하고 사용할 수는 있지만 여전히 오류가 발생합니다.

또한 Throw대신 수행 Throw Ex하면 전체 스택 추적을 유지할 수 있습니다. throw ex는 throw 문에서 스택 추적을 다시 시작합니다 (나는 그것이 의미가 있기를 바랍니다).

다른 많은 답변들이 예외를 다시 던지기를 원하는 이유에 대한 좋은 예를 제공하지만, '마지막'시나리오를 언급 한 사람은 없습니다.

예를 들어 커서를 설정하는 방법 (예 : 대기 커서)을 사용하는 방법이 있고이 방법에는 여러 개의 종료 점이 있습니다 (예 : if () return;). 방법의 끝.

이를 위해 모든 코드를 try / catch / finally로 랩핑 할 수 있습니다. 마지막으로 커서를 다시 오른쪽 커서로 설정하십시오. 유효한 예외를 묻지 않도록 캐치에서 다시 예외를 다시 던지십시오.

try
{
    Cursor.Current = Cursors.WaitCursor;
    // Test something
    if (testResult) return;
    // Do something else
}
catch
{
    throw;
}
finally
{
     Cursor.Current = Cursors.Default;
}

게시 한 코드의 예에서는 실제로 다시 잡을 수있는 캐치에 아무것도 수행되지 않으므로 예외를 포착 할 필요가 없습니다. 실제로 호출 스택이 손실되면 좋은 것보다 더 해가됩니다. .

그러나 예외가 발생하면 처리 할 호출 코드로 다시 던져야 할 경우 일부 논리 (예 : 파일 잠금의 SQL 연결 종료 또는 일부 로깅)를 수행하기 위해 예외를 잡을 수 있습니다. 비즈니스 계층을 구현하는 코더가 예외를 처리하도록하려면 프런트 엔드 코드보다 비즈니스 계층에서 더 일반적입니다.

게시 한 예제에서 예외를 포착 할 필요는 없지만 다시 반복하십시오. 그렇게하지 마십시오!

죄송하지만 "향상된 디자인"이라는 많은 사례는 여전히 끔찍한 냄새가 나거나 오해의 소지가 있습니다. {} catch {log; throw}는 전혀 의미가 없습니다. 예외 로깅은 응용 프로그램 내부의 중앙 위치에서 수행해야합니다. 어쨌든 예외가 스택 트레이스를 버블 링하는 이유는 무엇입니까?

컨텍스트 (예 : 하나의 예에서는 DTO)를 로그 메시지로 직렬화 할 때는주의해야합니다. 로그 파일에 액세스 할 수있는 모든 사람의 손에 닿기를 원하지 않는 민감한 정보를 쉽게 포함 할 수 있습니다. 그리고 예외에 새로운 정보를 추가하지 않으면 예외 래핑 지점이 실제로 보이지 않습니다. 좋은 오래된 Java에는 그 점이 있습니다. 호출자는 코드를 호출 할 때 어떤 종류의 예외를 예상해야하는지 알아야합니다. .NET에는이 기능이 없으므로 래핑은 내가 본 사례의 80 % 이상에서 아무런 효과가 없습니다.

다른 사람들이 말한 것 외에도 catch 및 rethrowing이 no-op가 아니라는 것을 보여주는 관련 질문에 대한 내 대답 을 참조하십시오 (VB에는 있지만 일부 코드는 VB에서 C # 호출 될 수 있음).

시나리오 catch-log-rethrow에 관한 대부분의 답변.

코드에서 코드를 작성하는 대신 OnExceptionOptions IncludeParameterValue 및 IncludeThisArgument와 함께 AOP, 특히 Postsharp.Diagnostic.Toolkit 을 사용하는 것이 좋습니다

를 통해 예외를 다시 던지기 throw 것은 현재 예외를 처리 할 특정 코드가 없거나 특정 오류 사례를 처리 할 논리가 있지만 다른 모든 것을 건너 뛰고 싶은 경우에 유용합니다.

예:

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException)
{
    if (numberText.ToLowerInvariant() == "nothing")
    {
        Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
    }
    else
    {
        throw;
    }
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

그러나 catch 블록에 조건절 을 사용하여이를 수행하는 다른 방법 도 있습니다 .

string numberText = "";
try
{
    Console.Write("Enter an integer: ");
    numberText = Console.ReadLine();
    var result = int.Parse(numberText);

    Console.WriteLine("You entered {0}", result);
}
catch (FormatException) when (numberText.ToLowerInvariant() == "nothing")
{
    Console.WriteLine("Please, please don't be lazy and enter a valid number next time.");
}    
finally
{
    Console.WriteLine("Freed some resources.");
}
Console.ReadKey();

이 메커니즘은 .NET 런타임이 예외 개체를 다시 던지기 전에 다시 작성하지 않아도되기 때문에 예외를 다시 던지는 것보다 효율적입니다.