예외 처리
1. [필수] RuntimeException에서 상속되는 Java 클래스 라이브러리에 정의된 런타임 예외 클래스(예: IndexOutOfBoundsException / NullPointerException)를 포착하지 마십시오.
긍정적 예:if(obj != null) {...}
카운터 예:try { obj.method() } catch(NullPointerException e){...}2. 필수 】예외 처리 효율성은 조건 분기보다 낮기 때문에 프로세스 제어나 조건 제어에는 예외를 사용해서는 안 됩니다.
3. [필수] 시도 - 큰 부분의 코드를 잡아보세요. 이는 무책임합니다. 캐치할 때 안정 코드와 비안정 코드를 구분하시기 바랍니다. 안정 코드란 무슨 일이 있어도 잘못되지 않는 코드를 말합니다. 불안정한 코드를 포착하려면 예외 유형을 최대한 구별한 후 해당 예외를 처리하십시오.
4. 처리하려면 예외를 잡아야 합니다. 처리하지 않고 처리하지 말고 예외를 호출자에게 던지세요. 가장 바깥쪽에 있는 비즈니스 사용자는 예외를 처리하고 이를 사용자가 이해할 수 있는 콘텐츠로 변환해야 합니다.
5. [필수] 트랜잭션 코드에 try 블록을 넣습니다. 예외를 포착한 후 트랜잭션을 롤백해야 하는 경우 트랜잭션을 수동으로 롤백해야 합니다. 6. [필수] finally 블록은 리소스 개체와 스트림 개체를 닫고 예외가 있는 경우 try-catch해야 합니다.
참고: JDK 7의 경우 try - with - 리소스 방법을 사용할 수 있습니다.
7. [필수] finally 블록에서는 Return을 사용할 수 없습니다. finally 블록의 return이 반환된 후에는 메서드 실행이 종료되며 try 블록의 return 문은 다시 실행되지 않습니다.
8. [필수] catch된 예외와 throw된 예외가 정확히 일치해야 합니다. 그렇지 않으면 catch된 예외가 throw된 예외의 상위 클래스입니다.
설명: 상대가 수국 공을 던질 것으로 예상했지만 실제로 포환던지기를 받으면 예상치 못한 상황이 발생합니다.
9. [권장] 메서드의 반환 값은 null일 수 있습니다. 빈 컬렉션이나 빈 개체를 반환하는 것은 필수가 아닙니다. 어떤 상황에서 null 값이 반환되는지 설명하기 위해 충분한 설명을 추가해야 합니다. 호출자는 NPE 문제를 방지하기 위해 null 판단을 수행해야 합니다.참고: 이 프로토콜에서는 NPE를 예방하는 것이 발신자의 책임임을 명확하게 명시합니다. 호출된 메서드가 빈 컬렉션이나 빈 개체를 반환하더라도 호출자는 가만히 앉아 있을 수 없으며, 원격 호출 실패, 런타임 예외 등의 시나리오에서 null이 반환되는 상황을 고려해야 합니다.
10. [권장 사항] NPE를 예방하는 것은 프로그래머의 기본 교육입니다.
1) 반환 유형은 null이 될 수 있는 압축된 데이터 유형입니다. int 값을 반환할 때 null 값에 주의하세요.
Counter 예: public int f() { return Integer object}; null인 경우 자동 unboxing에서 NPE가 발생합니다.
2) 데이터베이스의 쿼리 결과가 null일 수 있습니다.
3) 컬렉션의 요소가 isNotEmpty인 경우에도 검색된 데이터 요소는 null일 수 있습니다.
4) 원격 통화 반환 개체에는 항상 NPE 판단이 필요합니다.
5) Session에서 얻은 데이터에 대해 Null 포인터를 피하기 위해 NPE 검사를 수행하는 것이 좋습니다.
6) 일련의 호출은 obj . getA() . getC();
11. [권장사항] 코드에 "예외 발생" 또는 "오류 코드 반환"을 사용할지 여부, 회사 외부 http/api 개방형 인터페이스의 경우 "오류 코드"를 사용해야 합니다. 및 애플리케이션 내부적으로 예외를 발생시키는 것이 좋습니다. 애플리케이션 간 RPC 호출의 경우 Result 메서드가 선호되며 은 isSuccess, "오류 코드" 및 "오류 요약 메시지"와 함께 설치됩니다.
설명: RPC 메서드 반환 메서드에 Result 메서드를 사용하는 이유:
1) 예외 반환 메서드 사용 메소드가 캡처되지 않으면 런타임 오류가 발생합니다.
2) 스택 정보를 추가하지 않고 새로운 사용자 정의 예외만 추가하고 오류 메시지에 대한 자신의 이해를 추가하면 호출에 큰 도움이 되지 않습니다. 문제를 해결하기 위해. 스택 정보를 추가하게 되면 잦은 호출 오류가 발생할 경우 데이터 직렬화 및 전송 성능 저하 도 문제가 됩니다.
12. 확인되지 않은 예외와 확인된 예외를 구분하는 시간을 정의하고 RuntimeException을 사용하여 직접 발생시키는 것을 피하고 에서는 Exception 또는 Throwable을 발생시킬 수 없으며 비즈니스를 사용해야 합니다. 사용자 정의 예외를 의미합니다. DAOException / ServiceException 등과 같이 업계에서 정의된 권장 사용자 정의 예외입니다. 13. [참고] 중복 코드를 피하세요(Don't Repeat Yourself), 즉 DRY 원칙입니다.
참고:코드를 임의로 복사하여 붙여넣으면 필연적으로 코드 중복이 발생하므로 나중에 수정해야 할 경우 #의 모든 복사본을 수정해야 합니다. 🎜🎜#, 놓치기 쉽습니다. 필요한 경우 공통 메소드, 추상 공용 클래스 또는 공유 모듈을 추출하십시오. 긍정적인 예:
클래스에는 여러 공개 메소드가 있으며, 이때 모두 동일한 매개변수 확인 작업의 여러 행을 수행해야 합니다. , 추출해 주세요: # 🎜🎜#private boolean checkParam(DTO dto){...}
