서비스 계층이 모든 DAO 예외를 잡아서 서비스 예외로 포장해야합니까?

dao, 서비스 및 컨트롤러의 세 가지 계층 Spring 웹 앱이 있습니다. 컨트롤러는 dao를 직접 호출하지 않으며 서비스 계층을 통해 수행합니다. 현재 대부분의 경우 처리되지 않은 dao 예외 (런타임)가 있으면 최종 사용자에게 오류 메시지를 표시하는 JSP에 의해 포착됩니다. 서비스 계층이 모든 DAO 예외를 잡아서 서비스 예외로 포장해야합니까?

try {
   daoInstance.someDaoMethod();
} catch(DataAccessException dae) {
   throw new ServiceException("message", dae);
}

ServiceException도 런타임이고 처리되지 않는다고 가정 해 봅시다. ServiceException 대신 DataAccessException을 던지는 차이점이 있습니까? 프레젠테이션 레이어가 데이터 액세스 예외에 대해 알아야한다고 생각했습니다. 그러나 나는 그것을 막기 위해 회복 할 수없는 예외를 잡는 요점을 보지 못합니다.

중요한 요인은 서비스 클라이언트가 누구인지 생각합니다.

서비스 계층이 자체 프로젝트의 계층 간 아키텍처 경계이고 서비스 클라이언트가 동일한 트러스트 영역 내에 있으면 문제를 완화하고 확인되지 않은 예외가 컨트롤러 계층 또는 서비스 클라이언트에 버블 링되도록 할 수 있습니다.

그러나 공개 코드의 경우; 제 3 자 또는 고객이 소비하는 서비스의 경우, 주로 보안 문제, 두 번째 느슨한 결합 및 깨끗한 추상화를 위해 서비스 지향 예외로 검사되지 않은 예외를 래핑하는 것이 더 깨끗하다고 ​​생각합니다.

데이터 계층 예외는 웹 애플리케이션의 최종 사용자에게 직접 전달해서는 안됩니다 . 스키마, 쿼리, 줄 번호 정보, 변수 또는 함수 이름 등에 대한 내부 정보가 포함되어있을 수 있습니다. 최종 사용자 예외는 안전한 설정에서 삭제 될 수 있습니다.

외부 서비스 클라이언트는 구현 세부 사항과 관련이 없으며 검사되지 않은 예외는 버그 또는 환경 문제이므로 처리 할 수 ​​없습니다. 보안 응용 프로그램에서 데이터베이스 오류는 전파하기에 충분히 안전하지 않으므로 OracleException - ORA-01234 - ...삽입 된 세 번째 테이블 일 수 있습니다. 클라이언트는 처리 할 수있는 모든 확인 / 예상 예외를 처리하고 다른 모든 것을 잠재적 인 버그 보고서로 취급 할 수 있어야합니다. 서비스 계약은 원자적이고 일관된 트랜잭션 추상화 여야합니다. 예외에 대해 아무것도 할 수 없다면 남은 유용한 것은 버그 보고서 를 제공하는 것입니다.. 이미 예외를 기록 할 수있는 능력이 있으므로 최종 사용자에게 세부 정보를 제공해야하는 이유는 무엇입니까? 사용자가보고하기 전에 확인되지 않은 예외에 대해 이미 알 수 있도록 앱을 모니터링 할 수 있습니다.

예외 를 먹어도 괜찮지 만, 나는 예외를 좋아하지는 않지만 전반적인 제품의 특성에 적합한 계획을 세우는 것을 선호합니다.

아니요, 웹 응용 프로그램에서 DAO 예외를 래핑해서는 안됩니다.

제로 이익을 위해 코드에 많은 소음이 있습니다. DAO 예외는 적절한 이유로 검사되지 않은 예외입니다. 응용 프로그램 코드는 DAO 예외를 복구하는 데 유용한 작업을 수행 할 수 없습니다. 실제 문제는 다음과 같습니다.

... 최종 사용자에게 오류 메시지를 표시하는 JSP에 의해 포착됩니다.

전체 코드베이스를 크 래핑하는 대신 한 곳에서이 문제를 해결하십시오.

포착되지 않은 예외가 사용자에게 표시되는 방법을 제어합니다. 포착되지 않은 예외는 응용 프로그램 버그 또는 기본 시스템의 고장으로 인한 것입니다. 요청을 처리 할 수없는 이유에 대한 정보를 사용자에게 제공 할 이유가 없습니다. 사용자가 할 수있는 일은 없습니다. 친숙한 오류 페이지를 제공하기 만하면됩니다.

NB : 랩과 재 투입을위한 여러 가지 catch 블록을 생성하는 등 많은 지루한 코드를 작성하는 경우 거의 항상 더 나은 솔루션이 있습니다.

예외 래핑 을 사용하는 주된 이유 는 비즈니스 계층의 코드 가 시스템의 모든 가능한 예외에 대해 알 필요가 없도록하기 위해서 입니다. 이에 대한 두 가지 주요 이유가 있습니다.

• 일관성 : 선언 된 예외가 호출 스택의 상단으로 집계됩니다. 예외를 줄 바꿈하지 않고 대신 메소드를 선언하여 예외를 전달하면 여러 가지 예외를 선언하는 최상위 레벨 메소드로 끝날 수 있습니다. 각 메소드에서 이러한 모든 예외를 선언하면 호출 스택이 지루해진다.

• 캡슐화 : 최상위 구성 요소가 최하위 구성 요소 나 예외를 throw하는 것을 원하지 않을 수 있습니다. 예를 들어, DAO 인터페이스 및 구현의 목적은 나머지 응용 프로그램에서 데이터 액세스 세부 정보를 추상화하는 것입니다. 이제 DAO 메소드가 SQLException을 던지면 DAO를 사용하는 코드가 SQLException을 포착해야합니다. 데이터베이스가 아닌 웹 서비스에서 데이터를 읽는 구현으로 변경하면 어떻게 되나요? 그런 다음 DAO 메소드는 RemoteException과 SQLException을 모두 발생시켜야합니다. 또한 파일에서 데이터를 읽는 DAO가있는 경우 IOException도 발생시켜야합니다. 이는 각각 자체 DAO 구현에 바인딩 된 세 가지 예외입니다.

간단히 말해 대답은 '그렇다'입니다.