1.dao层我是直接抛出异常，都是比较“底层”的异常，比如DataAccessException. 不捕获的原因是，假如service调用了多个dao方法，其中有一个发生了异常，如果该dao方法自己捕获了又没有重新抛出来。这时候，service事务没法回滚，因为它以为都执行正确了。
2.在service里， 调用的dao方法有可能抛出DataAccessException的话，那么service也不捕获。因为DataAccessException是runtime异常，无需强制try-catch,况且，如果你捕获了又没有抛出来，配置的事务没法感知到，因为默认只处理runtime异常，当然可以配置。
3.还可以这样，在service方法里，dao方法外面直接try-catch(Throwable e). 然后重新抛出自定义的业务相关的异常。比如TopicUpdateException.
问题：上面1,2,3我对dao层，service层的方法处理是否合理。2,3哪种更好些？为什么？
4.接上面，这个自定义的业务异常的粒度要控制到什么级别？能否举个例子
5.上面2，3 我都是用的aop统一处理异常。我看大部分人也推荐这么做。因为service层各个方法里catch里的逻辑大都相似。使用aop统一处理，好处是显而易见的。我想知道，有什么弊端吗？因为我发现公司项目几乎没有这么做的。都是直接try-catch，返回结果。要么就是上面2里提到的不捕获。出了异常反正可以记录在log里
请大家帮忙看看
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
초대해주셔서 감사합니다! 하지만 저는 전문가가 아님을 선언해야 합니다 |_|
질문: 위의 1, 2, 3단계에서 dao 레이어와 서비스 레이어에 대한 접근 방식이 합리적인가요? 2, 3 중 어느 것이 더 좋나요?
우선 1, 2, 3단계 분석 및 이해에 동의합니다. 둘째,
3레이어가 더 이상 순수한 데이터 상호 작용이 아니라 일련의 비즈니스 논리 작업을 포함하기 때문에service처리가 더 적절하다고 생각합니다. 오류를 정확하게 설명할 수 있는 정보)는 로그에 기록되거나 트랜잭션 처리에 기록되는지에 관계없이 가능한 후속 수정/오류 문제 해결에 더 적합합니다.Throwable4. 위에서 계속해서 이 사용자 정의 비즈니스 예외의 세분성을 어느 수준까지 제어해야 합니까? 예를 들어주실 수 있나요
세부성은 요구 사항에 따라 다릅니다. 예를 들어 롤백만 수행하려는 경우이 잘못된 부분을 찾을 수 있으면 충분합니다. 하지만 그래도
service문제를 더 해결하고 싶다면 예외 메시지에 소스 오류에 대한 자세한 설명을 포함하는 것이 좋지 않을까요?root cause5. 위 2번과 3번에서는 예외를 균일하게 처리하기 위해 aop를 사용합니다. 대부분의 사람들이 이것을 추천한다고 생각합니다. 서비스 계층의 각 메서드에서 catch의 논리는 대부분 유사하기 때문입니다. 통합 처리를 위해 AOP를 사용하면 이점이 분명합니다. 알고 싶습니다. 단점이 있나요? 회사 프로젝트에서 이런 작업을 수행하는 경우가 거의 없다는 것을 알았기 때문입니다. 그것들은 모두 직접적인 try-catch 및 반환 결과입니다. 아니면 위 2번에서 언급한 비캡처입니다. 예외가 발생하면 로그에 기록 가능
먼저 귀사에서 그렇게 하지 않은 이유에 대해 이야기해 보겠습니다. 이는 이전에 프레임워크를 구축한 사람들이에 대해 충분히 알지 못했거나 개인적인 선호도 때문일 수 있습니다. 작업하고 어디든 직접 가기로 결정했습니다
"어쨌든 어떤 예외라도 로그에 기록될 수 있다"는 생각은 틀리지 않지만, 실제로 대용량 로그의 오류 메시지를 처리해 본 사람이라면 이해할 것이다. 균일하게 처리할 수 있는 것은 당연하지만 이루어지지 않는 것은 설계상의 결함이나 실수로 간주됩니다. 문제에 대한 가장 효과적인 해결책은 아닙니다aop(이 방법은 간단하고 투박하며 익히기 가장 쉽습니다)try catch는 건축가나 프로그래머를 막론하고 능숙하게 익히고 자유롭게 사용하려는 경우 디자인 패러다임으로 간주됩니다. 여전히 비용을 알아야 합니다(단점이 될 수 있음). 그 이유가 궁금하시다면 선배님들 몇 명과 비공개로 대화를 나누시는 것이 가장 좋으며, 다른 내부 정보도 얻으실 수 있을 것 같습니다^^aop
비전문가이니 가볍게 클릭해주세요^^Spring AOP를 사용하여 예외를 균일하게 처리하려면 물론 세 번째 방법이 더 좋습니다. Spring AOP를 사용하여 서비스 계층에서 발생한 예외를 가로채고, 처리되지 않은 모든 예외 로그를 기록하고, 처리되지 않은 모든 예외를 통합된 사용자 지정 시스템 예외로 변환하여 컨트롤러 계층이나 Rpc 계층이 이러한 사용자 지정 예외를 처리할 수 있도록 정보가 프런트 엔드로 피드백됩니다. 브라우저 측에 표시됩니다.
Spring AOP를 사용하여 예외를 가로채는 실제 기능은 예외 처리 논리를 일반 처리 논리에서 분리하는 것임을 잊지 마세요. 그렇다면 예외의 세분성은 어느 수준에서 제어된다고 생각하시나요? 이는 비즈니스 논리를 기반으로 합니다. 예를 들어 데이터베이스를 추가, 삭제, 수정, 확인하는 작업이 실패했습니까? 외부 인터페이스를 호출하지 못하셨나요? 기타 비정상적인 정보 등
귀사의 방식이 불규칙하고 부적절합니다. 로그를 처리할 때 각 try-catch 블록에 일부 처리 코드를 포함해야 하는 경우가 있습니다. 예외 처리 코드가 일반 실행 코드보다 많아 일반 실행 코드를 오염시키는 경우도 있습니다. 예외 처리 코드는 분산되어 있어 수정하기가 매우 까다롭습니다. 일부 예외는 균일하게 처리 및 수정할 수 없습니다.
Service의 비즈니스 메소드 명명이 미리 정의된 규칙에 따라 명명되지 않으면 AOP가 이를 차단할 수 없습니다. 즉, 트랜잭션 제어를 로드할 수 없습니다. 이러한 명명 규칙은 구성 파일에 지정되어야 합니다.
우리는 모두 컨트롤러 계층에서 aop 예외를 처리합니다
예외는 jquery를 사용하기 때문에 일부 프런트엔드 데이터가 완전히 분리되지 않은 비-ajax 예외와 ajax 예외로 구분됩니다. 백엔드에서 직접 렌더링됩니다.
ajax 예외:
비 ajax 예외:
ajax 예외 이외의 경우 프런트 데스크에서 고객에게 오류를 표시하는 방식이 확실히 다르기 때문에 Interceptor(필터)(aop)에서 별도로 처리합니다.
서비스 클래스의 각 메소드에서 전체 메소드를 try catch로 래핑한다고는 하지 않습니다. 그건 너무한 일입니다. 예외는 데이터베이스 예외, 널 포인터 등 제어할 수 없는 것으로 구분됩니다. 이것들은 잡을 필요가 없습니다. 서비스에서 비즈니스의 비정상적인 비즈니스를 기반으로 발생합니다. 예를 들어 사용자 이름이 반복되면 BizException("중복된 사용자 이름")이 발생합니다. 여기서 BizException은 RuntimeException
lz는 예외를 처리하기 위해 AOP를 언급했습니다. 서비스 계층에 있는지 아니면 컨트롤러 계층에 있는지는 알 수 없습니다. 위의 분석에 따르면 분명히 컨트롤러 계층에서 수행되어야 합니다.
이것이 최선의 답변이 아니라면 무리입니다Spring MVC를 사용하고 있나요? Spring MVC에는 전역 예외 처리 기능이 있습니다. 자세한 내용은 휴대폰에서 쉽게 표현할 수 없습니다.