자바 이상 처리 메커니즘 분석-고급 편
1.기 존의 이상 클래스 사용
예 를 들 어 IOException,SQLException.
try{ }catch(IOException ioe){ }catch(SQLException sqle){ }finally{ }
2.사용자 정의 이상 클래스
Exception 이나 Runtime Exception 의 하위 클래스 를 만 들 면 사용자 정의 이상 클래스 를 얻 을 수 있 습 니 다.예 를 들 면:
public class UserException extends RuntimeException {
public UserException() {
super();
// TODO Auto-generated constructor stub
}
3.사용자 정의 이상 사용
throws 성명 방법 으로 사용자 정의 이상 을 던 질 수 있 으 며,throw 문 구 를 사용 하여 적당 한 곳 에서 사용자 정의 이상 을 던 질 수 있 습 니 다.예 를 들 어 어떤 조건 에서 이상 을 던지다.
public void test1() throws UserException {
...
if(....){
throw new UserException ();
}
}
이상 전환(번역 이 라 고도 함)을 이상 하 게 읽 기 쉽 고 이해 하기 쉽게 한다.
public void test2() throws UserException {
...
try{
...
}catch(SQLException e){
...
throw new UserException ();
}
}
또 하나의 코드 가 있 습 니 다.아주 재 미 있 습 니 다.
public void test2() throws MyException{
...
try {
...
} catch (MyException e) {
throw e;
}
}
이 코드 는 실제 적 으로 이상 을 포착 한 후에 다시 털 어 놓 았 습 니 다.아무런 의미 가 없습니다.만약 에 이렇게 처리 할 만 한 것 이 있 으 면 처리 하지 않 으 면 됩 니 다.직접 방법 전에 throws 성명 으로 던 지면 되 지 않 습 니까?이상 한 포획 은 의미 있 는 처 리 를 해 야 한다.
JAVA 이상 처리 중 주의사항
JAVA 이상 체 제 를 합 리 적 으로 사용 하면 프로그램 을 건장 하고 선명 하 게 할 수 있 지만 불행 하 게 도 JAVA 이상 처리 체 제 는 자주 잘못 사용 된다.다음은 Exception 에 관 한 주의사항 이다.
1.checked Exception 을 무시 하지 마 십시오.
아래 코드 를 보십시오.
try
{ method1(); //method1 ExceptionA }
catch(ExceptionA e)
{ e.printStackTrace(); }
위의 코드 는 아무런 문제 가 없 는 것 같 습 니 다.이상 을 포착 한 후 이상 인쇄 를 한 다음 에 계속 실행 합 니 다.사실 catch 블록 에서 발생 하 는 이상 상황 에 대해 아무런 처리 도 하지 않 았 습 니 다.이러한 프로그램 은 계속 실 행 될 수 있 지만 이곳 의 조작 에 이상 이 발생 했 기 때문에 앞으로 의 조작 이 기대 하 는 상황 에 따라 발전 하지 못 하고 두 가지 결 과 를 초래 할 수 있 습 니 다.하 나 는 이곳 의 이상 으로 인해 프로그램 중의 다른 곳 에서 이상 을 던 졌 기 때 문 입 니 다.이런 상황 은 프로그래머 가 디 버 깅 할 때 혼 란 스 러 울 수 있 습 니 다.새로운 이상 이 던 진 곳 은 프로그램 이 진정 으로 문제 가 발생 하 는 곳 도 아니 고 문제 가 발생 하 는 진정한 원인 도 아니 기 때문이다.2.프로그램 이 계속 실행 되 고 잘못된 출력 결 과 를 얻 을 수 있 습 니 다.이런 문 제 는 더욱 포착 하기 어렵 습 니 다.왜냐하면 이것 을 정확 한 출력 이 라 고 생각 할 수 있 기 때 문 입 니 다.그럼 어떻게 처리 해 야 할 까요?여기 네 가지 선택 이 있 습 니 다.
4.567917.이상 을 처리 하고 프로그램 이 계속 실 행 될 수 있 도록 복원 합 니 다
4.567917.이상 을 다시 던 지고 이상 을 분석 한 후에 여기 서 처리 할 수 없다 는 것 을 발견 하면 이상 을 다시 던 져 호출 자 에 게 처리 하도록 한다
4.567917.이상 을 사용자 가 이해 할 수 있 는 사용자 정의 이상 으로 바 꾸 어 던 질 때 원본 이상 정 보 를 잃 어 버 리 지 않도록 주의해 야 합 니 다
이상 을 포착 하지 마 세 요
따라서 unchecked Exception 을 캡 처 할 때 이상 을 처리 해 야 합 니 다.여기 서 처리 할 필요 가 없다 고 판단 되면 이 이상 을 포착 하지 말고 방법론 에서 방법 에 이상 을 던 져 상부 호출 자가 처리 해 야 한다.
2.한 번 에 모든 이상 을 포착 하지 마 세 요.
아래 코드 를 보십시오.
try
{
method1(); //method1 ExceptionA
method2(); //method1 ExceptionB
method3(); //method1 ExceptionC
}
catch(Exception e)
{
……
}
이것 은 매우 매력 적 인 방안 이다.코드 에 catch 자 구 를 사용 하여 모든 이상 을 포착 하여 완벽 하고 간결 해 보이 지만 사실은 많은 코드 도 이렇게 쓰 여 있다.그러나 여기 에는 두 가지 잠재 적 인 결함 이 있 습 니 다.하 나 는 try 블록 에서 던 진 모든 Exception 에 대해 서로 다른 처리 와 회복 조치 가 필요 할 수 있 습 니 다.여 기 는 catch 블록 만 있 기 때문에 각각 처리 하면 실현 되 지 않 습 니 다.둘째,try 블록 에서 Runtime Exception 을 던 질 수도 있 습 니 다.코드 에서 던 질 수 있 는 모든 Runtime Exception 을 캡 처 하여 처리 하지 않 았 습 니 다.프로 그래 밍 오 류 를 감 추 면 프로그램 이 디 버 깅 하기 어 려 울 수 있 습 니 다.다음은 수정 후의 정확 한 코드 입 니 다.
try
{
method1(); //method1 ExceptionA
method2(); //method1 ExceptionB
method3(); //method1 ExceptionC
}
catch(ExceptionA e)
{
……
}
catch(ExceptionB e)
{
……
}
catch(ExceptionC e)
{
……
}
3.이상 은 대상 의 상태 에 영향 을 주지 않 습 니 다
이상 이 발생 한 후 대상 의 상태 에 영향 을 주어 서 는 안 된다.이것 은 이상 처리 중의 중요 한 규칙 이다.한 함수 에서 이상 이 발생 한 후 대상 의 상 태 는 이 함 수 를 호출 하기 전에 일치 해 야 대상 이 정확 한 상태 에 있 는 지 확인 할 수 있 습 니 다.대상 이 가 변 적 이지 않 은 대상 이 라면(가 변 적 이지 않 은 대상 은 구조 함 수 를 호출 하여 만 든 후 바 꿀 수 없 는 대상 을 말 합 니 다.즉,만 든 후 대상 의 상 태 를 바 꿀 수 있 는 방법 이 없습니다)이상 이 발생 한 후 대상 의 상 태 는 변 하지 않 을 것 입 니 다.가 변 대상 이 라면 프로 그래 밍 에서 이상 이 대상 상태 에 영향 을 주지 않도록 주의해 야 한다.이 목적 을 달성 할 수 있 는 세 가지 방법 이 있다.1.이상 이 발생 할 수 있 는 코드 와 대상 상 태 를 바 꿀 수 있 는 코드 를 분리 하고 이상 이 발생 할 수 있 는 코드 를 먼저 실행 하 며 이상 이 발생 하면 대상 상 태 를 바 꾸 는 코드 를 실행 하지 않 는 다.2.이상 코드 가 쉽게 분리 되 지 않 고 대상 상태 코드 를 바 꾸 는 방법 에 대해 recover 방법 을 정의 합 니 다.이상 이 발생 한 후에 recover 방법 으로 변 경 된 클래스 변 수 를 복원 하고 복원 방법 이 호출 되 기 전의 클래스 상 태 를 복원 합 니 다.3.방법 에서 대상 의 복사 본 을 사용 하면 이상 이 발생 한 후에 영향 을 받 는 것 은 복사 일 뿐 대상 자체 가 영향 을 받 지 않 습 니 다.
4.잃 어 버 린 이상
아래 코드 를 보십시오.
public void method2()
{
try
{
……
method1(); //method1
}
catch(SQLException e)
{
……
throw new MyException(“ :”+e.getMessage);
}
}
public void method3()
{
try
{
method2();
}
catch(MyException e)
{
e.printStackTrace();
……
}
}
위의 method 2 코드 에서 try 블록 은 method 1 에서 던 진 데이터베이스 이상 SQLException 을 캡 처 한 후 새로운 사용자 정의 이상 MyException 을 던 졌 습 니 다.이 코드 에 문제 가 없 는 지 는 모 르 겠 지만 콘 솔 의 출력 을 보 세 요.
MyException:데이터베이스 이상 발생:대상 이름'MyTable'이 잘못 되 었 습 니 다.at MyClass.method2(MyClass.java:232) at MyClass.method3(MyClass.java:255)
원본 이상 SQLException 의 정 보 를 잃 어 버 렸 습 니 다.method 2 에서 정 의 된 MyException 의 스 택 상황 만 볼 수 있 습 니 다.한편,method 1 에서 발생 하 는 데이터베이스 이상 스 택 은 보이 지 않 습 니 다.어떻게 잘못 배열 합 니까?method 1 의 코드 줄 에서 한 줄 만 데이터베이스 조작 문 구 를 찾 습 니 다.method 1 의 방법 체 가 짧 기 를 기도 합 니 다.
5.이상 메커니즘 과 반환 값 을 동시에 사용 하여 이상 처 리 를 하지 마 십시오.
다음은 우리 프로젝트 의 코드 입 니 다.
try
{ doSomething(); }
catch(MyException e)
{ if(e.getErrcode == -1) { …… }
if(e.getErrcode == -2)
{ …… }
……
}
만약 시간 이 지나 서 이 코드 를 본다 면,당신 은 무슨 뜻 인지 알 수 있 습 니까?JAVA 이상 처리 메커니즘 과 반환 값 을 혼합 해 프로그램의 이상 처리 부분 을'추 하 게'만 들 고 이해 하기 어렵다.여러 가지 이상 이 있 으 면 위의 코드 처럼 Exception 과 반환 값 을 종합 적 으로 사용 하지 말고 여러 가지 이상 을 정의 합 니 다.수 정 된 정확 한 코드 는 다음 과 같 습 니 다.
try
{ doSomething(); // MyExceptionA MyExceptionB }
catch(MyExceptionA e)
{ …… }
catch(MyExceptionB e)
{ …… }
6.try 블록 을 너무 크게 만 들 지 마 세 요.
편리 한 목적 으로 많은 사람들 이 커 다란 try 블록 으로 이상 이 발생 할 수 있 는 모든 코드 를 포함 하 는 데 익숙 하 다.그러면 두 가지 나 쁜 점 이 있다.1.코드 를 읽 을 때 try 블록 의 지루 한 코드 에서 어떤 코드 가 어떤 이상 을 던 지 는 지 알 기 쉽 지 않 고 코드 유지 에 불리 하 다.2.try 캡 처 이상 을 사용 하 는 것 은 프로그램 실행 효율 을 대가 로 하 는 것 입 니 다.캡 처 이상 코드 를 try 블록 에 포함 시 키 지 않 아 도 코드 실행 효율 에 영향 을 줍 니 다.
총결산
자바 이상 에 대해 거시적인 것 에서 응용 에 이 르 기 까지 우 리 는 간단 한 이 해 를 가지 게 되 었 다.그러면 코드 를 쓸 때 이상 에 대해 정확 한 처 리 를 하고 오류 와 번 거 로 움 을 피하 여 우리 의 시스템 을 더욱 건장 하고 아름 답 게 해 야 한다.다시 한 번 말씀 드 리 지만 프로그램 을 작성 할 때 인성 화 된 로그 출력 이 필요 합 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Is Eclipse IDE dying?In 2014 the Eclipse IDE is the leading development environment for Java with a market share of approximately 65%. but ac...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.