사용자 지정 예외를 만드는 이유는 무엇입니까?

사용자 지정 예외를 만드는 이유는 무엇입니까?

---

사용자 지정 예외를 생성해야하는 이유 .NET?

---

특정 세관 예외를 사용하면 catch 문에 대해 서로 다른 오류 유형을 분리 할 수 ​​있습니다. 예외 처리를위한 일반적인 구조는 다음과 같습니다.

try
{}
catch (Exception ex)
{}

이것은 유형에 관계없이 모든 예외를 포착 합니다 . 그러나 사용자 지정 예외가있는 경우 각 유형에 대해 별도의 처리기를 가질 수 있습니다.

try
{}
catch (CustomException1 ex1)
{
    //handle CustomException1 type errors here
}
catch (CustomException2 ex2)
{
    //handle CustomException2 type errors here
}
catch (Exception ex)
{
    //handle all other types of exceptions here
}

Ergo, 특정 예외를 사용하면 예외 처리를보다 세밀하게 제어 할 수 있습니다. 이 이점은 사용자 지정 예외뿐 아니라 .NET 시스템 라이브러리의 다른 모든 예외 유형에서도 공유됩니다.

---

최근에이 주제에 대한 긴 블로그 게시물을 작성했습니다.

http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

핵심은 다음과 같습니다. 다음 중 하나에 해당하는 경우에만 사용자 지정 예외 생성

1. 실제로 누군가가 그것을 처리하기를 기대합니다.
2. 특정 오류에 대한 정보를 기록하려는 경우

---

따라서 직접 던진 다음 잡아서 그 의미를 정확히 알 수도 있습니다.

또한 : 클래스 라이브러리 / 프레임 워크 / api를 빌드하는 경우 코드의 다른 예외가 상속하는 BaseException을 만드는 것이 종종 유용합니다. 그러면 코드에서 예외가 발생할 때이를 사용하는 프로그래머는 예외의 원인을 빠르게 알 수 있습니다.

---

의도를 명확하게 할 수 있고 IDE 기능을 사용하여 사용량을 추적 할 수도 있기 때문입니다. "FooBar"라는 사용자 정의 백엔드 시스템이 있고 "FooBarDownException"을 작성한다고 가정하면이 예외의 사용을 추적하여 FooBar가 다운 되었기 때문에 애플리케이션에 포함 된 사용자 정의 로직을 식별 할 수 있습니다. 이 특정 유형의 예외를 포착하고 다른 예외를 무시하도록 선택하여 예외 처리기 내의 오버로드 및 조건부 논리를 피할 수 있습니다. 이것은 강력한 타이핑의 또 다른 버전 일뿐입니다. 또한 예외에는 의도를 드러내는 이름 이 있기 때문에 코드에서 주석을 피할 수 있습니다 .

---

"기술적으로"왜 그런지 잘 모르겠지만 권한을 사용하는 앱 / 웹 사이트가 있다고 가정 해 보겠습니다. 누군가에게 올바른 권한이 없다면 DivideByZero 예외 또는 IOException을 던지는 것은 어리석은 일입니다. 대신 나중에 디버그하는 데 도움이되는 AccessDeniedException을 만들 수 있습니다.

---

.NET이 아닌 응용 프로그램에 대해 다른 종료 코드를 만드는 것과 같은 이유는 다른 응용 프로그램 관련 오류를 지정하는 것입니다. 같은 ... ConnectionBrokenException아니면 음 ... UserSmellsBadException... 또는 뭔가.

이렇게하면 정확히 무엇이 잘못되었는지 파악하고 적절하게 행동 할 수 있습니다. 예를 들어 일부 데이터를 보내려고 할 때 데이터 전송 클래스가를 throw ConnectionBrokenException하면 다시 연결 대화 상자를 표시하고 다시 연결을 시도 할 수 있습니다. 그런 다음 reconnect 메서드가 ConnectionTimeoutException시간 초과되면 a를 throw하고 다시 적절하게 작동 할 수 있습니다.

---

또 다른 이유는 클라이언트가 인터페이스와 대화 할 때입니다. 클라이언트는 인터페이스의 구현을 인식하지 못하고 다른 예외를 던질 수 있기 때문에 발생한 오류를 균일화하기 위해 사용자 지정 예외를 만드는 것이 좋습니다.

이 특별한 경우에 대해 썼습니다.

http://blog.mikecouturier.com/2010/01/creating-custom-exceptions-in-net-right.html

---

Joel이 썼 듯이 : 그래서 당신은 그것들을 스스로 던진 다음 그들을 잡아서 그들이 의미하는 바를 정확히 알 수 있습니다.

또한 예외 처리기가보다 정확하게 작동하도록하기 위해 문제에 대한 특정 정보를 추가 할 수 있습니다.

---

표준 .NET 예외는 모든 응용 프로그램에서 잘못 될 수있는 모든 문제를 다루지 않으며 의도하지도 않습니다. 프로그램이 매우 단순하지 않다면 최소한 몇 가지 사용자 지정 예외를 만들어야 할 것입니다.

---

우선, 예외는 언어가 아닌 라이브러리에서 구현됩니다. 라이브러리에서 예외를 어떻게 만들 수 있습니까? 나는 당신이 시스템 라이브러리가 다른 규칙 세트를 가져야한다고 주장하지 않을 것이라고 확신합니다.

다른 경우에는 실제로 예외의 개체 트리를 사용할 수 있습니다. 상속 된 예외는 원하는 경우 특수 속성을 가질 수 있습니다.이 속성은 실제보다 더 복잡한 작업에 사용할 수 있습니다. 나는 그들이 일반적인 데이터 전송 메커니즘이나 다른 것으로 사용되도록 옹호하지는 않지만 (그럴 수도 있지만) 누군가가 예외에 대한 특수 속성이 필요한 사용자 지정 로깅 솔루션을 구현 한 경우를 볼 수 있습니다.

사용자 정의 예외에는 특수 처리를 나타내는 플래그가 포함될 수 있으며 (JVM을 다시 시작해야 함을 의미하는 것일 수 있음) 로깅 수준에 대한 정보, 많은 정보를 포함 할 수 있습니다.

어쨌든, 저는 이걸 옹호하는 것이 아니라 가능하다고 말하고 있습니다. 첫 번째 단락은 당신의 진정한 대답입니다.

---

내장 된 예외가 문제 / 예외를 적절하게 설명하면 안됩니다. 사용자 지정 ArgumentException, ArgumentNullException또는 을 만들기 위해 자체 기본 클래스를 만들지 않습니다 InvalidOperationException.

고유 한 예외를 만들고 더 높은 수준에서 오류를 설명 할 수 있습니다. 그러나 이것은 일반적으로 소비자 클래스에서 디버깅하는 데 그다지 도움이되지 않습니다.

직접 예외를 throw하고 catch하는 경우 사용자 지정 예외가 순서대로있을 수 있습니다.

ReferenceURL : https://stackoverflow.com/questions/417428/why-create-custom-exceptions