예외의 세분성

나는 같은 그들은 일반적으로 예외를 선호하는 몇 친구들과 나 사이의 논쟁으로 실행했습니다 ClientErrorException와 ServerErrorException내가 일을 더 구체적인을 선호하는 반면, 예외의 필드와 세부 사항. 예를 들어 다음과 같은 몇 가지 예외가있을 수 있습니다.

• BadRequestException
• AuthenticationFailureException
• ProductNotFoundException

이들 각각은 API에서 반환 된 오류 코드를 기반으로 작성되었습니다.

예외의 장점에 따라 이것은 Java에 관용적 인 것처럼 보입니다. 그러나 내 친구의 의견은 드문 일이 아닙니다.

코드 가독성 및 API 유용성 측면에서 선호되는 방법이 있습니까?

많은 다른 예외 클래스를 갖는 것과 오류 텍스트에 더 자세한 정보를 가진 소수의 클래스를 갖는 것의 주요 차이점은 많은 다른 예외 클래스가 호출 코드가 다른 종류의 오류에 다르게 반응하도록 허용한다는 것입니다. 소수의 클래스만으로 모든 종류의 예외를 균일하게 처리 할 수 ​​있습니다.

이것은 일반적으로 트레이드 오프입니다. 상속을 사용하여 어느 정도 완화 할 수 있습니다 (일반적으로 모든 것을 포착하고 기록하려는 발신자의 경우 일반 기본 예외 클래스, 다른 반응이 필요한 발신자의 경우 기본 클래스에서 파생 된 예외). 주의하지 않고 YAGNI 원칙을 고수하면 불필요한 복잡성이 많이 발생합니다. 따라서 안내 질문은 여기에 있어야합니다.

• 코드의 호출자가 다른 제어 흐름과 함께 다른 종류의 오류에 대해 다르게 반응 할 것으로 기대하십니까?

이것에 대한 하나의 크기에 맞는 솔루션은 없으며, 모든 곳에서 적용 할 수있는 브레인 데드 "모범 사례"는 없습니다. 이 질문에 대한 답변은 어떤 종류의 소프트웨어 또는 구성 요소를 디자인 하느냐에 따라 크게 달라집니다.

• 일부 응용 프로그램, 귀하 또는 팀이 귀하의 통제하에 전체 코드 기반을 가지고 있습니까?

• 또는 잠재적 인 발신자를 모두 모르는 타사의 일부 재사용 가능한 구성 요소입니까?

• 다른 종류의 오류가 전체 시스템을 즉시 중단하지 않아야하며 다른 종류의 오류 완화가 필요할 수있는 장기 실행 서버 응용 프로그램?

• 사용자에게 오류 메시지를 표시 한 다음 프로세스를 다시 시작하기에 충분한 오류가 발생하는 짧은 응용 프로그램 프로세스?

따라서 구성 요소의 잠재적 호출자에 대해 더 많이 알수록, 실행에 대한 정확한 세부 사항 레벨을 더 잘 결정할 수 있습니다.

대답은 우리가 말하는 오류보고 수준에 따라 다릅니다.

일반적으로 나는 당신의 친구들과 동의하는데, 문제의 원인을 전달하는 데 필요한 것보다 더 세분화해서는 안됩니다.

null 참조 (NullReferenceException)에 대해 잘 알려진 일반적인 예외가있는 경우 고유 한 MyObjectIsNullException을 생성해서는 안됩니다. 그것은 단지 인간 통역사에게 혼란의 층을 추가 할 것입니다.

근본 원인을 다루는 사전 정의 된 예외가 없다는 특별한 예외가있는 경우에만 자신을 작성해야합니다.

그러나 거기서 멈추지 않아도됩니다. 일반적인 오류는 구성 요소 중 하나에서 발생할 수 있으며 문제가 있었다 전달 할 수 있습니다 구성 요소에가 . 그래서 무엇이 잘못 됐는지뿐만 아니라 어디에서도. 그런 다음 MyComponentException에서 첫 번째 예외를 래핑하는 것이 적절합니다. 그것은 당신에게 두 세계의 최고를 줄 것입니다.

먼저 구성 요소에 문제가 발생한 것이 분명합니다. 하단 레버에서 구체적인 원인은 내부 예외입니다.