다음은 제 개인적인 연습일 뿐이며 참고용입니다.

Controller 레이어:
AOP 또는 Filter의 개입 없이 여기 메서드 내에서 생성된 모든 예외 를 처리해야 한다고 개인적으로 생각합니다.

레이어: DAO이 레이어의 예외는 대부분 SQL 예외이며 일반적으로 처리를 위해
레이어에 발생합니다. Service

예외에 호출자의 개입이 필요하지 않다고 판단되면 서비스 내에서 처리되고, 그렇지 않으면 처리를 위해 호출자에게 전달됩니다(실제로는 전송입니다. 책임감...) Service
잡은 다음 다른

을 사용하는 것과 결합됩니다. 예: catch A, B, C 예외는 모두 Exception의 D 예외 처리기에 의해 처리됩니다. AOP

개인적으로 예외 포착의 원칙은 코드에 예상되는 예외에 대한 비즈니스 처리가 필요한 경우에만 예외를 포착하면 된다고 생각합니다. 예를 들어 SQL 오류가 발생하면 트랜잭션을 롤백해야 합니다. 다른 예외는 기본적으로 예외를 잡을 필요가 없습니다. 레이어 비즈니스는 예외를 균일하게 처리할 수 있습니다.

몇 가지 개인적인 제안:

(1) 확인된 예외는 RuntimeException으로 변환됩니다. 이를 발생시키는 것은 일반적으로 버그로 간주됩니다
(2) 사용자 정의 예외(비즈니스 예외)는 RuntimeException에서 상속됩니다. 종료 시 로그 정보를 통해 이상 상황을 빠르게 재현할 수 있습니다.
(3) 예외 발생 여부와 관련하여 일반적으로 호출자가 비즈니스 예외가 발생할 수 있고 이를 처리할 수 있다는 것을 알아야 하는 경우 예외를 발생시킵니다. 호출자가 예외를 처리할 수 없으면 예외가 포착됩니다. 즉, "책임을 전가"하지 마십시오.
(4) 강력히 권장하지 않습니다catch Exception. 이런 종류의 코드는 예외가 발생했을 때 문제를 빨리 찾기 어렵게 만듭니다.

Dao 레이어에서 직접 위쪽으로 예외를 발생시키는 것이 좋습니다(일반적으로 데이터베이스 런타임 예외). Service 레이어는 다른 애플리케이션에 노출되며, 전달해야 할 비즈니스 정보가 많이 있습니다. 상위 계층 호출자이므로 여기에 두 가지 방법이 있습니다

1. 비즈니스 예외를 발생시켜 특정 비즈니스 예외 정보/시스템 예외 정보를 호출자에게 알립니다(시스템 예외, 상위 계층에서는 주의를 기울이지 않을 수 있음)

2. Service은 예외가 발생하지 않도록 하고 상위 계층에 Result을 반환합니다. Result에 포함된 정보는 호출 성공 여부와 실패할 경우입니다. 일부 비즈니스 정보

따라서 모든 수준에서 예외를 포착할 필요는 없습니다. 처리하려면 Service(단일 애플리케이션이든 향후 서비스이든)에서 처리하면 됩니다. 서비스는 팀에 따라 다릅니다

try{}catch{}를 사용하여 일반 비즈니스 프로세스를 제어해야 할까요, 아니면 if()를 사용하여 제어해야 할까요