2009-09-09 5 views
1

데이터를 데이터베이스에 유지하기 위해 최대 절전 모드를 사용하는 일부 EJB가 있습니다. 나는이 EJB와 대화하는 두꺼운 Swing 클라이언트를 가지고있다. 클라이언트는 데이터베이스에 대해 아무것도 모릅니다 (드라이버 항아리가 없음).적절한 EJB 예외 처리 - 클라이언트의 ClassNotFoundException

하나의 트랜잭션 동안 Hibernate ConstraintViolationException이 발생할 수 있습니다. 나는 모든 예외를 잡아과 같이 넣어지고있는 EJBException에서 그들을 포장 :

catch(HibernateException e) { 
    e.printStackTrace(); 
    throw new EJBException(e); 
} 

내가 무엇입니까 문제는 예외가 클라이언트 측에서 JBoss의 호출자에 의해 비 정렬 화 될 때, ClassNotFoundException가이 있기 때문에 (PSQLException에 대한) 슬로우됩니다 있다는 것입니다 클라이언트에는 classpath에 sql 드라이버 jar가 없습니다.

이 응용 프로그램을 변경하여 스택 추적 기록을 가질 수 있도록이 예외 응용 프로그램을 항상 ejbexception 생성자에 전달합니다. 이제는 원래 개발자가이 작업을 수행하지 않은 이유를 알아 냈습니다.

이 시점에서 저는 클라이언트와 함께 postgres 드라이버 jar를 포함하거나 catch 된 예외를 EJBException 생성자에 전달하는 것을 제거하는 두 가지 옵션을 봅니다. 다른 사람들이 다른 제안을 갖고 있고 다른 사람들이 EJB에서 예외를 처리하는 방법이 있다면 궁금합니다.

답변

2

제 생각에는 최종 사용자 인 클라이언트가 문제의 기술적 인 세부 사항을 알 필요가 없다는 것입니다. 따라서 다양한 레이어 경계에서 기술적 예외를 일반적인 "XYZ 오류"로 변환하는 것은 상당히 합리적입니다.

사용 된 구성표는 서버가 예외가 발견 된 지점에서 고유 한 오류 번호를 할당하는 것입니다. 그런 다음 해당 번호를 포함하여 로그에 진단을 씁니다. 클라이언트에게보고 된 메시지에는 단순히 번호 만 포함됩니다. 그런 다음 지원 데스크는 특정 오류 번호를 통해 문제에 대한 사용자의 보고서를 상호 연관시킬 수 있습니다.

+0

+1 "클라이언트는 기술적 세부 사항을 알 필요가 없습니다." 그래도 고유 한 오류 번호 접근 방식은 완전히 불필요하다고 생각합니다. 모든 고객은 "서버 오류가 발생했습니다"라는 사실을 알아야합니다. 서버 로그는 문제를 해결하는 데 필요한 모든 정보를 제공해야합니다. – ChssPly76

+0

많은 사용자가 있고 오류보고에서 항상시기 적절하거나 정확한 것은 아니며 단순하지 않은 n 계층 아키텍처가있는 경우이 오류 번호가 실제로 작동하고 불필요한 것이 아니라고 생각합니다. 구현할 작업량은 사소한 것입니다. – djna

+0

제 잘못입니다. 나는 "불필요한"만큼 "무의미한"것을 의미하지는 않았다 :-) 우리는이 접근법을 시도해 보았고 실제 오류 번호가 모든 경우의 약 0.5 %에서 우리에게 되돌아 왔음을 발견했다. 나머지는 "어떤 종류의 오류"또는 "창이 팝업"으로보고되었습니다. 하지만 아마도 사용자가 내 것보다 낫다 - 나는 단지 당신을 부러워 할 수있다 :-) – ChssPly76