내 응용 프로그램은 구성 가능한 항목이 많은 구성 파일을 사용합니다.나쁜 구성에 대한 확인되지 않은 예외를 던지는 것이 좋은 생각입니까?
예를 들어, 기본 JVM javax.net.ssl.keystore 대신 WebService 연결에 사용할 사용자 정의 별칭을 사용하여 사용자 정의 키 저장소를 지정할 수 있습니다.
런타임 중에이 별칭이 키 저장소에 없기 때문에 예외가 발생할 수 있습니다. 이것은 응용 프로그램의 중요한 부분이기 때문에 (그리고 구성이 고정 될 때까지 응용 프로그램이 제대로 작동 할 것이라고 기대할 수는 없습니다.) 여기에 체크되지 않은 예외를 던지면 좋은 생각입니다.
그런 식으로 생각하니?
이 경우에는 ConfigurationException (RuntimeException까지 확장) 사용자 정의를 만드는 것이 합리적일까요?
확인 된 예외가 발생하여 메서드의 사용자에게 특정 예외가 발생할 수 있음을 알립니다. 그래서 사용자가 예외를 얻을 때해야 할 일을 결정할 수 있습니다.
"구성이 올바른 경우가 아니면 계속 진행해서는 안됩니다."사용자가 try-catch 블록에서이를 우회하도록 실행할 수있는 방법이없는 경우 확인 된 예외를 만들 이유가 없습니다. (사용자가 쓸모가 없다는 것을 알면 불필요한 작업을하는 이유).
그래서이 경우에는 확인되지 않은 예외로 이동합니다.
체크 예외를 작성해야하고 catch 할 때 메시지 또는 무언가를 표시 한 후 catch 블록에서 프로그램을 종료해야한다고 생각합니다. 검사되지 않은 예외는 프로그래밍 오류에 대한 것이므로 개발자가 수정해야합니다. 확인 예외는 발생할 수있는 조건에 대한 것이지만 우리는 예외를 제어 할 수 없습니다. 구성 파일이 손상되었을 수도 있지만 일어날 수 없으며 제어 할 수도 없습니다. 내가 확인 된 예외로 갈 것입니다.
체크되지 않은 예외는 프로그램의 버그 또는 시스템 오류를 나타냅니다. 예를 들어 ArrayIndexOutOfBoundsException 또는 NullPointerException은 프로그램에서 발생하지 않아야하며, 발생하는 경우 일반적으로 버그를 나타냅니다.
직접 입력 또는 사용자 입력을 구성 파일을 통해 사용자 입력의 유효성을 검사 할 때 예외는 버그를 나타내지 않습니다. 따라서, 예외를 발생시킬 가능성이없고 잡히지 않으면 메소드를 호출 한 프로그래머에게 상기시키기 위해 검사 된 예외가되어야합니다. 예외를 잡아 냄으로써 사용자 친화적 인 오류 메시지를 생성 할 수 있습니다. 최종 사용자가 Java에서 생성 한 Exception in thread ... 메시지를 보지 못하도록하십시오.
답장을 보내 주셔서 감사합니다. 당신은 디폴트'RuntimeException'을 가지게 될 것인가, 아니면 특별히 설정을 가리키는 확장 된 커스텀 예외를 만들겠습니까? – Davio
나는 관습에 갈 것이다 ... (나는 대답 한 사람이 아니지만 대답으로 기다린다) – Hichamov
나는 훨씬 더 세밀한 통제를 제공 할 것이므로 나는 관습에 갈 것이다. – Ouney