횡적으로 처리할 예외사항이 있고, 그렇지못한 예외사항이 있고로 구분할 필요가 있다고 생각합니다. 말씀하신 부분은 횡적으로 처리할 예외사항과 그렇지 못한 예외사항이 섞여있는 느낌이여요.

회사 업종은 게임인데, 사내에서는 @ControllerAdvice 를 통해 일반적인 예외처리를 하고 있기는 합니다. 다만, 상황에 따라 try/catch 를 활용하여 다른 예외처리를 필요에 따라 사용중입니다.

@김문수 '횡적으로' 라고 말씀하신 부분의 의미를 설명해 주실수 있을까요? 궁금합니다.

@로프

객체지향을 넘어 관점지향으로 AOP

토비 이일민님의 AOP 관련 글인데 "AOP의 필요성" 문단까지만 보셔도 '횡적으로'(횡단 관심사)라는 표현을 이해하실 때 도움이 될 것 같아요.

원문은 찾을 수가 없어서 구글 저장된 페이지 링크 남깁니다.

checked와 unchecked 종류로 구분해서 구성하지는 않는가 보군요! 프레임워크를 exception 관리에 대한 정의가 필요가 해서 물어본거였는데... 아직은 적절한 해답을 찾지 못했습니다.

무조건적으로 UnChecked Exception이 능사는 아니겠지만 ... 아래 링크의
Checked Exception(SQLException)을 UnChecked Exception(DataAccessException)으로 래핑한 이유도 고려해 볼만 할 것 같아요.

자바지기님의_DAO리팩토링_강의자료

"DAO 리팩토링 5 - SQLException을 DataAccessException으로 래핑" 부분

자바 언어가 등장하면서 장점 중의 하나가 Exception 클래스의 도입이었다. 
그런데 Checked Exception이 남용되면서 소스 코드가 지저분해지는 경향이 생기면서 
최근에는 Checked Exception의 사용을 최소화하자는 방향으로 흐름이 바뀌였다. 
하지만 기존 API에는 수 많은 Checked Exception이 있다. 
이 Checked Exception을 그대로 사용하는 것이 아니라 UnChecked Exception(Runtime Exception)으로 
래핑해서 사용하는 것이 더 깔끔한 코드를 유지하는데 도움이 된다.

스프링의 DataAccessException

As this class is a runtime exception, 
there is no need for user code to catch it 
or subclasses if any error is to be considered fatal (the usual case).

객체지향을 넘어 관점지향으로 AOP

그렇다면 그 많은 로그 처리와 보안, 트랜잭션 관리, 예외상황 처리등의 코드는 어디로 간 것인가? 
그 부분은 독립된 형태의 단일 모듈로 각각 작성이 되고 AOP를 통해서 필요한 시점에서
핵심 코드에 삽입되어져 동작하게 된다.

부분 바로 위 예제의 "AccountException" 역시 UnChecked Exception일 것 같네요.