범용 클래스에서 예외를 catch하지 않는 것이 가장 좋은 이유는 무엇입니까?

Question

일부 범용 목적으로 클래스를 구현할 때 예외를 catch하지 않는 것이 가장 좋은 이유는 무엇입니까?

오류가 스택을 올라가 디버깅 프로세스에 도움이 될 수 있다고 생각합니다. 다른 이유가 있습니까?

Answer 1

이 규칙은 다음과 같이 잘 읽어야합니다. 처리하지 마십시오. 처리 방법을 모름!

예 : CSV 파일을 읽고 줄의 토큰을 반환하는 클래스를 작성하면 클래스에 IOException이 발생할 수있는 몇 가지 사항이 생깁니다. 그것을 처리하는 것은 당신의 책임이 아니기 때문에 당신은 확실히 그것을 잡지 말아야합니다! 귀하의 작업은 바이트 스트림을 토큰 스트림으로 변환하는 것입니다. 누군가가 당신에게 부패한 시냇물을 건네 주면, 당신이 아니라 그 사람이 처리해야합니다.

EDIT : 예를 들어 라이브러리가 SocketException에 도달하여 호출자로부터 소켓에 lib가 제공된 경우 SocketException을 전달하십시오. 라이브러리가 추상 연결 프레임 워크 일 경우 파일, 메모리 등에 연결할 수 있으며 SocketExceptions은 일반적인 것이 아니며 ConnectionException에 랩핑합니다.

Answer 2

더 많은 객체 지향적이며 구현 세부 사항을 숨 깁니다. 방법 그것을 수행 하는 작업에 더 명백한 관련이 없으며 예외가 발생하는 경우

그것은 당황 :

으로는 효과적인 자바 조슈아 블로흐는 말했다. 이는 메서드가 낮은 수준의 추상화로 을 던져 예외를 전달할 때 자주 발생합니다. 뿐만이 아니라, 구현 세부 사항으로 상위 계층의 API 인 을 오염시킵니다. 후속 릴리스에서 상위 계층 구현이 변경되면 예외가 발생하여 도 변경되어 기존 클라이언트 프로그램이 손상 될 수 있습니다. 이 문제를 방지하려면 문제가 발생합니다. 상위 계층에서는 하위 예외를 catch하고 해당 장소에는 상위 수준 인 추상화로 설명되는 이 될 수있는 예외를 throw해야합니다.

Answer 3

잡기가 끝난 후에 할 일이 있다면 예외를 잡아도 좋습니다. 예를 들어, 웹 서비스 호출을 시도한 후에 IOException이 발생했다고 가정합니다. 특정 상황에서 예외를 포착하고 통화를 다시 시도하는 것이 좋습니다.

잡기 예외는 적절하게 처리하지 않고 삼킨 경우 "나쁜 것"이됩니다. 이 경우 예외를 throw하는 것이 더 효과적이며 더 높은 수준에서 다루는 것이 더 명확합니다. 의미하고 처리 할 수 ​​있습니다 경우에만

Answer 4

"Throw early catch late!"

예외가 잡힐 것이다. 아이디어는 응용 프로그램의 계층까지 예외를 전파하여 사용자 또는 비즈니스 논리가 예외와 관련하여 어떤 조치를 취할 수있는 지점으로 전파하는 것입니다.