예외 처리의 일반적인 오류

예외는 Java(또는 기타) 프로그램의 정상적인 실행 흐름이 중단되는 것입니다. 이 위반은 메모리 액세스 위반, 0으로 나누기, 초기화 문제, 불법 명령 실행 또는 기타 치명적인 오류로 인해 발생할 수 있습니다. Java는 원치 않는 모든 시나리오를 적절하게 처리할 수 있지만 개발자가 이러한 Java 기능을 사용하는 경우 몇 가지 문제가 발생할 수 있습니다. 이 기사에서는 Java 에서 예외 처리가 어떻게 작동하는지 논의하지 않을 것입니다 . 나는 독자가 이미 예외 계층 구조, 확인된 예외 , 확인되지 않은 예외 및 런타임 예외 에 익숙 하다고 가정합니다 . 여기서는 피해야 할 가장 일반적인 실수에 대해 논의하겠습니다.

예외의 이해관계자

실행 스레드가 중단될 때마다 이에 대한 정보가 프로그램 실행자에게 반환되어야 합니다. 이 스레드는 화면, 일괄 작업 또는 다른 방식으로 시작할 수 있습니다. 이러한 모든 트리거는 특정 형식의 메시지를 전송하기 위해 흐름에서 일종의 위반이 발생할 때까지 기다립니다. 화면 기반 트리거는 기술적인 문제가 있음을 부드럽게 알려줄 수 있으며 도움과 조언을 위해 지원팀에 문의해야 합니다. 일괄 처리 또는 독립형 Java 프로그램에서는 오류 보고서가 최종 사용자가 완전히 이해할 수 없는 일종의 로그 형식으로 나타날 것으로 예상할 수 있습니다. 하지만 사업가들은 그들이 이해할 수 있는 언어로 메시지를 받아야 합니다. 사용자의 마음 속에 있는 두려운 NullPointerException은 매우 짜증스럽습니다. 이러한 오류는 프로그램을 잘못 사용하여 발생하는 경우도 있지만 수정이 필요한 문제인 경우도 있습니다. 두 번째 중요한 이해관계자는 예외로 인해 발생하는 문제를 처리해야 하는 사람입니다. 이 사람은 예외가 발생할 때 프로그램의 실제 실행을 관찰할 수 없습니다. 이는 두 가지에 의존합니다. 첫 번째는 문제가 있는 사용자가 제공한 정보이고 두 번째는 예외가 발생할 때 생성된 일종의 로그입니다. 또한 문제를 분석하는 사람은 프로그램을 작성한 사람이 아니므로 프로그램 개발자는 분석을 위한 충분한 정보를 제공해야 합니다. 프로그램 개발자와 디버거 간의 유일한 통신 방법은 로그입니다. 또한 때로는 보안상의 이유로 로그 로그에 예외가 발생했을 때 프로그램 실행에 대한 실제 세부 정보가 모두 포함되지 않을 수도 있습니다. 예외 처리에서 발생할 수 있는 오류를 살펴보겠습니다. 그들 중 일부는 꽤 어리석어 보이지만 사람들이 있습니다. 이러한 오류가 문제로 이어질 때까지 주의를 기울이지 않는 사람.

빈 예외 블록

이는 예외 처리에서 가장 원치 않는 오류 중 하나입니다. 이 경우 예외는 단순히 무시됩니다. 솔루션에는 예외를 남기기 위한 주석 줄만 포함되어 있습니다. try{ }catch(SQLException sqe){ // do nothing } 데이터베이스가 종료될 때 마지막 블록과 같은 일부 드문 경우에는 예외가 발생할 수 있습니다. 이 경우 무시할 수 있습니다. try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }

예외 메시지의 잘못된 일반화

이 점은 주관적입니다. 예외를 포착한 후 친근한 메시지 형식으로 최종 사용자에게 보고할 수 있습니다. 원본 메시지가 하나의 일반 메시지로 변환되면 원본 메시지의 세부 정보가 손실될 가능성이 높습니다. 메시지는 최종 사용자에게 적절한 정보를 전달해야 지원 팀에 문의할 때 사용자는 적절한 로그에 로그인하여 정보를 제공하기만 하면 됩니다. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } 다중 계층 애플리케이션에서 각 계층은 예외를 포착하고 새로운 유형의 예외를 발생시킵니다. 때로는 특정 유형의 예외를 캐스팅하는 것이 절대적으로 필요합니다. - 데이터 액세스 계층 -> DataAccessException 생성 - 비즈니스 구현 계층 -> BusinessException 생성 - 애플리케이션 서비스 계층 -> ApplicationServiceException 생성 모든 것이 논리적인 것 같지 않습니까? 여기서는 둘 다 동일한 정보를 나타낼 수 있으므로 ApplicationServiceException과 BusinessException 중에서 선택해야 할 수도 있습니다. 이러한 예외 변환 중 하나는 불필요한 것 같습니다.

StackTrace 클래스 삭제

예외를 새로운 특수 유형으로 변환하는 과정에서 스택 추적이 사라져 예외의 실제 원인을 추적하는 것이 악몽이 될 수 있습니다. 아래 코드에서는 원래 예외로부터 어떤 정보도 받지 않고 새 예외가 발생하는 방법을 볼 수 있습니다. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }

예외 사유 덮어쓰기

각 예외 메시지에는 예외 이유에 대한 정보가 포함되어 있습니다. 단, 새로운 예외가 생성되면 이전 예외에 대한 정보가 영구적으로 삭제될 수 있습니다. 이는 새로운 예외가 발생하여 StackTrace가 제거될 수 있는 위의 예와 유사합니다.

특정 예외를 검색하지 않음

때때로 개발자는 예외를 처리할 때 안전하게 플레이하고 싶어합니다. 때로는 이것이 쉬운 일입니다. 그러나 특정 예외 대신 java.lang.Exception을 포착하는 것은 허용되지 않습니다. try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }

불필요한 캐치 앤 던지기

예외를 다른 유형으로 변환하려는 경우 또는 최종 사용자나 분석가에게 보내는 예외 메시지에 일부 정보를 추가하는 데 도움이 되는 경우 예외를 포착하세요. 그렇지 않으면, 잡는 대신 메소드 시그니처(throw 사용)에서 더 멀리 버리십시오.

런타임 예외 잡기

RuntimeException을 포착하지 않는 것이 좋습니다. 대신 특정 예외를 포착하여 처리하는 것이 좋습니다.

확인되지 않은 예외 찾기

확인되지 않은 예외를 포착할지 여부는 논란의 여지가 있는 주제입니다. NullPointerException 및 ArrayIndexOutOfBound는 확인되지 않은 예외의 가장 좋은 예일 수 있습니다. 이러한 예외를 포착하는 대신 이러한 시나리오를 처리하도록 코드를 변경할 수 있습니다. 예를 들어 NullPointerException을 방지하고, 모든 변수가 초기화되었는지 확인하고, ArrayIndexOutOfBound 예외를 방지하고, 올바른 길이의 배열을 정의하는 등의 작업을 수행합니다.

예외 로깅과 관련된 문제

잡지는 두 번째 관심 있는 사람, 즉 문제를 분석하는 사람에게 도움이 될 것입니다. 때로는 개발자가 로그 파일을 과도하게 사용하여 애플리케이션의 모든 수준에서 로그가 생성되는 경우가 있습니다. 로그에는 예외가 발생한 수준의 예외가 기록되어야 합니다. 프로그램 실행을 중지하거나 계속하라는 제안과 함께 예외가 발생했다는 경고를 표시하고 로그에 예외를 의무적으로 기록하는 것이 최적인 것 같습니다.

흐름 제어 예외

예외는 프로그램의 정상적인 흐름을 방해하는 것입니다. 즉, 이 흐름을 중단하고 최종 사용자에게 이에 대해 알려야 함을 의미합니다. 대체 스레드인 메서드 호출을 추가하면 엄청난 유지 관리 문제가 발생합니다. try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }

java.lang.Exception의 유비쿼터스 사용

모든 예외에 대해 모든 곳에서 java.lang.Exception을 사용하는 것도 좋은 생각이 아닙니다. 대신, 애플리케이션별 예외나 가장 적절한 표준 Java 예외를 사용하는 것이 더 좋습니다. 원본 기사: 예외 처리의 일반적인 실수 번역 및 음성: Ve4niY