문제

사용자 정의 예외를 언제 던져야합니까?

예를 들어 서버에 연결하는 코드가 있습니다. 서버에 연결되는 코드는 연결하지 못할 때 ioexception을 던집니다. 그것이 불리는 방법의 맥락에서, 이것은 괜찮습니다. 네트워크 코드에서도 괜찮습니다.

그러나 이것은 연결이없고 작동하지 않기 때문에 예외는 UI까지 끝납니다. 이 단계에서 IOException은 매우 모호합니다. NoconnectionException과 같은 것이 더 나을 것입니다.

그래서 내 질문은 : 추상화에 더 잘 맞는 다른 (맞춤형) 예외를 던지기 위해 어떤 단계에서 예외를 포착해야합니까?

도움이 되었습니까?

해결책

나는 원래 방법을 요청한 것과 관련하여 예외가 예외를 기대할 것입니다. 예를 들어

read -> ReadException
connect -> ConnectException
buildPortfolio -> FailedToBuildPortfolioException

등. 이것은 덮개 아래에서 일어나는 일을 추상화합니다 (즉, 소켓을 통해 연결하고 있습니까). 일반적으로 구성 요소에 대한 인터페이스를 만들 때 종종 해당 예외 또는 예외 세트를 만듭니다. 내 인터페이스가 호출됩니다 Component, 내 예외는 보통입니다 ComponentException (예 : RateSource 그리고 RateSourceException). 전체 구성 요소 세트로 다른 프로젝트로 내보내기가 일관되고 쉽습니다.

단점은 많은 예외를 만들고 많은 번역을 수행해야 할 수도 있다는 것입니다. 거꾸로 (당신이 식별 한대로) 추상화 누출이 거의 없다는 것입니다.

메소드 호출 계층 구조 (및 예외) 시점에서 회복이 발생할 수 없다고 결정할 수 있으며 (또는 부적절한 위치에 있음) 나중에 처리되지 않은 예외로 번역됩니다.

다른 팁

나는 이것이 "언어에 대한 언어"로 태그된다는 것을 알고 있지만, 나는 그것이 실제로 그렇게 생각하지 않습니다. C ++ 관점에서 나오면 기본 작업이 예외를 던지기를 거의 기대하지 않습니다. 따라서 내 자신의 코드는 종종 예외를 생성 할 수있는 첫 번째 장소입니다. 이 코드에서 나는 매우 평평한 계층 구조를 좋아합니다. 나중에 코드의 나중에 수백 개의 Catch () 조항을 엉망으로 만들고 싶지 않으며, 클래스와 네임 스페이스의 바로크 한 상속인을 만드는 것에 대한 Java와 C#의 명백한 강박 관념을 결코 이해하지 못했습니다.

따라서 C ++ 코드의 경우 라이브러리 당 의미있는 오류 메시지가 포함 된 한 가지 예외 유형. 그리고 하나는 최종 실행 파일을위한 것입니다.

여기에는 두 가지 질문이 숨겨져 있다고 생각합니다. a) 언제 다른 예외 뒤에 예외를 숨겨야하는지. b) 이에 대해 사용자 정의 예외를 사용하는시기.

a) 나는 말하고있다 : 예외는 애플리케이션에서 두 레이어의 경계를 가로 질러 여행 할 때마다 새 계층에 더 적합한 예외 뒤에 숨겨져 있어야한다. 예 : 원격 작업을 수행하고 있으므로 설명이 발생하면 연결됩니다.

그러나 발신자는 연결 문제를 인식해서는 안됩니다. 그는 단지 일부 서비스를 받기를 원하기 때문에 ServiceOforDerexception을 얻습니다. 그 이유는 다음과 같습니다. 레이어 내부에서 원격을 수행하면 ConnectionException으로 유용한 작업을 수행 할 수 있습니다 (재시도, 백 아웃 큐에 기록하십시오.). 해당 레이어를 떠나면 ConnectionException을 처리하는 방법을 아무도 모릅니다. 그러나 서비스가 작동하지 않을 때, 무엇을하는지 결정할 수 있어야합니다.

b) 기존 예외가 일치하지 않는 경우. 예를 들어 Java에는 몇 가지 유용한 예외가 있습니다. 나는 불법 상태와 불법을 자주 사용합니다. 새로운 예외 클래스에 대한 강력한 주장은 제공 할 유용한 컨텍스트가있는 경우입니다. 예를 들어 실패한 서비스 이름은 ServiceFailedException의 주장 일 수 있습니다. 모든 메소드 호출에 대한 클래스 나 그 효과에 대한 클래스를 만들지 마십시오. 100 예외 클래스는 행동이 다르면 (즉, 적어도 다른 필드)가있는 한 문제가되지 않습니다. 이름으로 만 다르고 동일한 추상화 수준에 상주하면 한 가지 예외를 만들고 메시지 또는 해당 예외 클래스의 단일 필드에 다른 이름을 넣으십시오.

c) 적어도 Java에서는 점검 된 예외에 대한 논의가 있습니다. 나는 점검 된 종류를 싫어하기 때문에 확인되지 않은 사람으로 직접 포장합니다. 그러나 그것은 더 많은 의견입니다.

IO 문제로 인해 발생하지 않는 NoconnectionException을 얻을 경우가 있습니까? 반대로, 원인이 IO를 기반으로하는지 또는 클라이언트가 현명하게 회복하는 데 도움이되지 않을지 아는가?

사용자 정의 예외를 언제 던져야합니까?

I. 더 많은 (진단) 정보를 제공 할 수있는 경우.

참고 :이 추가 정보는 원래 예외 (IOException)가 발생한 장소에서 사용할 수 없습니다. 점진적인 추상화 계층의 추상화 층은이 예외를 이끌어 내려고했던 것과 같은 더 많은 정보가있을 수 있습니까?

II. 구현 세부 정보를 노출해서는 안되는 경우 : 즉, (Illusion of?) 추상화가 계속되기를 원합니다.

이것은 기본 구현 메커니즘이 변경 될 수있는 경우 중요 할 수 있습니다. 사용자 정의 예외로 기본 예외를 마무리하는 것은 클라이언트를 구현 세부 정보에서 단열하는 좋은 방법입니다 (추상화 수준을 높이면)

III. I와 II

참고 : 또한 고객은 관심있는 정확한 수준의 정보를 조정할 수 있어야하거나 관심이없는 모든 정보를 조정할 수 있어야합니다. 따라서 IOException에서 사용자 정의 예외를 도출하는 것이 좋습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top