프로젝트를 위해 현재 작업하고있는 패키지에는 약 13 가지 사용자 정의 예외가 있습니다. 이러한 예외를 사용할 모든 클래스가있는 패키지 아래의 하위 패키지에 이들을 배치하는 것이 좋습니다. 예를 들어예외를 자체 하위 패키지에 배치 하시겠습니까?
:
com.company.project.core
는 COM
의 내부에 배치 된 일부 사용자 지정 예외를 던질 수있는 클래스의 무리를 포함 .company.core.exception
지금보고있는 유일한 단점은 예외를 사용하는 클래스에 대해 더 많은 수입이 있다는 것입니다.
예외가 다른 패키지에 들어가야한다고 생각하지 않습니다. 프로젝트의 다른 클래스에 연결되어 있기 때문입니다. 패키지가 너무 많은 클래스가 많으면 그 패키지를 분할해야하지만 기능적 기준으로 분할하는 것이 좋습니다.
어쨌든 너무 많은 예외 클래스가있는 경우 예외가 여러 개있는 예외 대신 throw 될 수있는 기본 예외 클래스를 고려해야합니다. MyProjectException과 같은 것.
예, 예외 패키지는 유용한 아이디어이며, 존경할만한 IDE를 사용하면 어쨌든 가져 오기를 처리해야하는 문제를 피할 수 있습니다.
대부분의 프로그래머에게는 RuntimeExceptions를 사용할 지 또는 자체 예외 계층에 대해 예외를 검사할지 여부는 훨씬 더 어려운 질문입니다.
이것은 약간 주관적인 질문이지만 별도의 패키지가 필요하지는 않습니다. 사용자 정의 예외는 동일한 패키지 내의 클래스와 관련되어 있으므로 동일한 패키지에 두는 것이 정당합니다.
사용자 지정 예외가 자체 하위 패키지에있는 경우 사용하는 API의 예는 생각할 수 없습니다. 확실히 JDK는 그렇지 않습니다.
정의 할 예외의 수를 감안할 때 하위 패키지를 사용하는 것이 좋습니다. 핵심 패키지를 더 단정하게 유지할 것입니다. core.exceptions의 패키지 구조에서 예외 클래스가 무엇인지 관련된 것이 명확하므로 Mnementh의 의견에 동의하지 않습니다.
예, 기능적 분리. 유형별로 결정된 물리적 분리가 아닙니다. 그렇지 않으면 x.y.interfaces 및 x.y.abstract와 같은 다른 분류에 대한 선례를 설정하게됩니다. – Robin
일부 전후에 특수화 된 예외의 일부를 리팩토링하고 이미 존재하는 "기본 예외 클래스"를보다 유용하게 만들기로 결정했습니다. –