Java 예외 처리에 대한 오해와 경험 요약에 대한 자세한 소개

이 기사는 Java 예외 선택 및 사용에 대한 몇 가지 오해에 초점을 맞추고 있습니다. 독자들이 예외 처리의 요점과 원칙을 숙지하고 요약 및 귀납에 주의하시기 바랍니다. 예외 처리를 통해서만 개발자의 기본적인 읽고 쓰는 능력을 향상시키고, 시스템의 견고성을 향상시키며, 사용자 경험을 향상시키고, 제품의 가치를 높일 수 있습니다.

오해 1. 예외 선택

그림 1. 이상 분류

그림 1은 이상 구조를 설명합니다. , 사실 우리 모두는 이상 현상이 감지된 이상과 감지되지 않은 이상으로 구분된다는 것을 알고 있지만 실제로는 이 두 가지 이상 현상의 적용이 혼동됩니다. 확인되지 않은 예외는 사용하기가 매우 쉽기 때문에 많은 개발자는 확인된 예외가 거의 쓸모가 없다고 생각합니다. 실제로 비정상적인 애플리케이션 시나리오는 다음과 같이 요약할 수 있습니다.

1. 호출 코드는 계속 실행할 수 없으며 즉시 종료되어야 합니다. 이 상황에는 서버를 연결할 수 없거나 매개변수가 올바르지 않은 등 여러 가지 가능성이 있습니다. 확인되지 않은 예외는 호출 코드를 명시적으로 포착하고 처리할 필요가 없고 코드가 간결하고 명확하므로 이러한 상황에 적용할 수 있습니다.

2. 호출 코드에 추가 처리 및 복구가 필요합니다. SQLException이 감지되지 않은 예외로 정의된 경우 개발자는 데이터를 작동할 때 호출 코드에서 SQLException을 명시적으로 캡처하고 처리할 필요가 없으며 이로 인해 심각한 연결이 닫히지 않고 트랜잭션이 롤백되지 않고 더티 데이터가 발생한다는 것을 당연하게 여깁니다. SQLException은 감지된 예외로 정의되므로 개발자는 코드가 예외를 생성한 후 명시적으로 이를 포착하고 리소스를 정리해야 합니다. 물론 리소스를 정리한 후에도 감지되지 않은 예외를 계속 발생시켜 프로그램 실행을 방지할 수 있습니다. 관찰과 이해를 바탕으로 이상 징후 탐지는 대부분 도구 클래스에 적용될 수 있습니다.

오해 2: 페이지나 클라이언트에 직접 예외를 표시합니다.

클라이언트에서 직접 예외를 인쇄하는 예는 JSP를 예로 들어 보겠습니다. 코드가 실행될 때 예외가 발생하면 기본적으로 컨테이너는 예외 스택 정보를 직접 인쇄합니다. 페이지에서. 실제로 고객의 관점에서 보면 예외는 실질적인 의미가 없습니다. 대부분의 고객은 예외 정보를 전혀 이해할 수 없습니다. 소프트웨어 개발에서는 사용자에게 직접 예외를 표시하지 않도록 노력해야 합니다.

목록 1

 package com.ibm.dw.sample.exception;
/**
 * 自定义 RuntimeException
 * 添加错误代码属性
 */
public class RuntimeException extends java.lang.RuntimeException { 
     //默认错误代码 
    public static final Integer GENERIC = 1000000; 
    //错误代码
    private Integer errorCode; 
     public RuntimeException(Integer errorCode, Throwable cause) {
            this(errorCode, null, cause);
     }
     public RuntimeException(String message, Throwable cause) {
            //利用通用错误代码
            this(GENERIC, message, cause);
     }
     public RuntimeException(Integer errorCode, String message, Throwable cause) {
            super(message, cause);
            this.errorCode = errorCode;
     }
     public Integer getErrorCode() {
            return errorCode;
     } 
}

샘플 코드와 같이 예외에 오류 코드를 도입하고, 일단 예외가 발생하면 예외의 오류 코드만 제시합니다. 사용자에게 알리거나 오류 코드를 보다 이해하기 쉬운 프롬프트로 변환합니다. 실제로 여기에 있는 오류 코드에는 또 다른 기능도 포함되어 있습니다. 개발자는 오류 코드를 기반으로 어떤 유형의 예외가 발생했는지 정확하게 알 수도 있습니다.

오해 3. 코드 계층 오염

우리는 종종 코드를 서비스, 비즈니스 로직, DAO 등과 같은 여러 계층으로 나눕니다. DAO 계층에는 예외 발생 Listing 2에 표시된 메서드:

Listing 2

public Customer retrieveCustomerById(Long id) throw SQLException {
 //根据 ID 查询数据库
}

위 코드는 언뜻 보기에는 문제가 없어 보이지만, 디자인 결합. 여기서 SQLException은 상위 계층 호출 코드를 오염시켰으며 호출 계층은 이를 포착하거나 더 높은 수준으로 전달하기 위해 명시적으로 try-catch를 사용해야 합니다. 디자인 격리 원칙에 따라 다음과 같이 적절하게 수정할 수 있습니다.

목록 3

public Customer retrieveCustomerById(Long id) {
     try{
            //根据 ID 查询数据库
     }catch(SQLException e){
            //利用非检测异常封装检测异常，降低层次耦合
            throw new RuntimeException(SQLErrorCode, e);
     }finally{
            //关闭连接，清理资源
     }
}

오해 4. 예외 무시

다음 예외 처리는 콘솔에 예외만 출력하므로 이는 의미가 없습니다. 더욱이 여기서 예외가 발생했지만 프로그램을 중단하지 않았으며 호출 코드가 계속 실행되어 더 많은 예외가 발생했습니다.

목록 4

 public void retrieveObjectById(Long id){
   try{
       //..some code that throws SQLException
    }catch(SQLException ex){
     /**
       *了解的人都知道，这里的异常打印毫无意义，仅仅是将错误堆栈输出到控制台。
       * 而在 Production 环境中，需要将错误堆栈输出到日志。
       * 而且这里 catch 处理之后程序继续执行，会导致进一步的问题*/

          ex.printStacktrace();
     }
}

는 다음과 같이 재구성될 수 있습니다.

목록 5

public void retrieveObjectById(Long id){
 try{
    //..some code that throws SQLException
 }
 catch(SQLException ex){
    throw new RuntimeException(“Exception in retieveObjectById”, ex);
 }
 finally{
    //clean up resultset, statement, connection etc
 }
}

이 오해는 상대적으로 기본적인 , 일반적인 상황에서는 이러한 간단한 실수가 발생하지 않습니다.

오해 5.

루프 문 블록에 예외를 포함합니다

다음 코드와 같이 for 루프 문 블록에 예외가 포함됩니다.

목록 6

for(int i=0; i<100; i++){
    try{
    }catch(XXXException e){
         //….
    }
}

예외 처리가 시스템 리소스를 소비한다는 사실은 모두가 알고 있습니다. 언뜻보기에 모두는 그런 실수가 일어나지 않을 것이라고 생각했습니다. 다른 관점에서 보면 클래스 A에서 루프가 실행되고 클래스 B의 메서드가 루프에서 호출됩니다. 그러나 클래스 B에서 호출되는 메서드에는 try-catch와 같은 명령문 블록이 포함되어 있습니다. 클래스 계층 구조를 제거한 후의 코드는 위와 완전히 동일합니다.

오해 6. Exception을 사용하여 모든 잠재적인 예외를 포착합니다.

코드 단순성을 위해 여러 가지 유형의 예외가 발생합니다. 다음 예에 표시된 대로 모든 잠재적인 예외가 발생합니다.

목록 7

public void retrieveObjectById(Long id){
    try{
        //…抛出 IOException 的代码调用
        //…抛出 SQLException 的代码调用
    }catch(Exception e){
        //这里利用基类 Exception 捕捉的所有潜在的异常，如果多个层次这样捕捉，会丢失原始异常的有效信息
        throw new RuntimeException(“Exception in retieveObjectById”, e);
    }
}

는

목록 8

public void retrieveObjectById(Long id){
    try{
        //..some code that throws RuntimeException, IOException, SQLException
    }catch(IOException e){
        //仅仅捕捉 IOException
        throw new RuntimeException(/*指定这里 IOException 对应的错误代码*/code,“Exception in retieveObjectById”, e);
    }catch(SQLException e){
        //仅仅捕捉 SQLException
        throw new RuntimeException(/*指定这里 SQLException 对应的错误代码*/code,“Exception in retieveObjectById”, e);
    }
}

误区七、多层次封装抛出非检测异常

如果我们一直坚持不同类型的异常一定用不同的捕捉语句，那大部分例子可以绕过这一节了。但是如果仅仅一段代码调用会抛出一种以上的异常时，很多时候没有必要每个不同类型的 Exception 写一段 catch 语句，对于开发来说，任何一种异常都足够说明了程序的具体问题。

清单 9

try{
    //可能抛出 RuntimeException、IOExeption 或者其它；
    //注意这里和误区六的区别，这里是一段代码抛出多种异常。以上是多段代码，各自抛出不同的异常
}catch(Exception e){
    //一如既往的将 Exception 转换成 RuntimeException，但是这里的 e 其实是 RuntimeException 的实例，已经在前段代码中封装过
    throw new RuntimeException(/**/code, /**/, e);
}

如果我们如上例所示，将所有的 Exception 再转换成 RuntimeException，那么当 Exception 的类型已经是 RuntimeException 时，我们又做了一次封装。将 RuntimeException 又重新封装了一次，进而丢失了原有的 RuntimeException 携带的有效信息。

解决办法是我们可以在 RuntimeException 类中添加相关的检查，确认参数 Throwable 不是 RuntimeException 的实例。如果是，将拷贝相应的属性到新建的实例上。或者用不同的 catch 语句块捕捉 RuntimeException 和其它的 Exception。个人偏好方式一，好处不言而喻。

误区八、多层次打印异常

我们先看一下下面的例子，定义了 2 个类 A 和 B。其中 A 类中调用了 B 类的代码，并且 A 类和 B 类中都捕捉打印了异常。

清单 10

 public class A {
 private static Logger logger = LoggerFactory.getLogger(A.class);
 public void process(){
     try{
     //实例化 B 类，可以换成其它注入等方式
     B b = new B();
     b.process();
     //other code might cause exception
    } catch(XXXException e){
       //如果 B 类 process 方法抛出异常，异常会在 B 类中被打印，在这里也会被打印，从而会打印 2 次
       logger.error(e);
       throw new RuntimeException(/* 错误代码 */ errorCode, /*异常信息*/msg, e);
       }
    }
}
public class B{
 private static Logger logger = LoggerFactory.getLogger(B.class);
    public void process(){
        try{
            //可能抛出异常的代码
        }
        catch(XXXException e){
            logger.error(e);
            throw new RuntimeException(/* 错误代码 */ errorCode, /*异常信息*/msg, e);
        }
 }
}

同一段异常会被打印 2 次。如果层次再复杂一点，不去考虑打印日志消耗的系统性能，仅仅在异常日志中去定位异常具体的问题已经够头疼的了。

其实打印日志只需要在代码的最外层捕捉打印就可以了，异常打印也可以写成 AOP，织入到框架的最外层。

误区九、异常包含的信息不能充分定位问题

异常不仅要能够让开发人员知道哪里出了问题，更多时候开发人员还需要知道是什么原因导致的问题，我们知道 java .lang.Exception 有字符串类型参数的构造方法，这个字符串可以自定义成通俗易懂的提示信息。

简单的自定义信息开发人员只能知道哪里出现了异常，但是很多的情况下，开发人员更需要知道是什么参数导致了这样的异常。这个时候我们就需要将方法调用的参数信息追加到自定义信息中。下例只列举了一个参数的情况，多个参数的情况下，可以单独写一个工具类组织这样的字符串。

清单 11

public void retieveObjectById(Long id){
    try{
        //..some code that throws SQLException
   }catch(SQLException ex){
        //将参数信息添加到异常信息中
        throw new RuntimeException(“Exception in retieveObjectById with Object Id :”+ id, ex);
   }
}

误区十、不能预知潜在的异常

在写代码的过程中，由于对调用代码缺乏深层次的了解，不能准确判断是否调用的代码会产生异常，因而忽略处理。在产生了 Production Bug 之后才想起来应该在某段代码处添加异常补捉，甚至不能准确指出出现异常的原因。这就需要开发人员不仅知道自己在做什么，而且要去尽可能的知道别人做了什么，可能会导致什么结果，从全局去考虑整个应用程序的处理过程。这些思想会影响我们对代码的编写和处理。

误区十一、混用多种第三方日志库

现如今 Java 第三方日志库的种类越来越多，一个大项目中会引入各种各样的框架，而这些框架又会依赖不同的日志库的实现。最麻烦的问题倒不是引入所有需要的这些日志库，问题在于引入的这些日志库之间本身不兼容。如果在项目初期可能还好解决，可以把所有代码中的日志库根据需要重新引入一遍，或者换一套框架。但这样的成本不是每个项目都承受的起的，而且越是随着项目的进行，这种风险就越大。

怎么样才能有效的避免类似的问题发生呢，现在的大多数框架已经考虑到了类似的问题，可以通过配置 Properties 或 xml 文件、参数或者运行时扫描 Lib 库中的日志实现类，真正在应用程序运行时才确定具体应用哪个特定的日志库。

其实根据不需要多层次打印日志那条原则，我们就可以简化很多原本调用日志打印代码的类。很多情况下，我们可以利用拦截器或者过滤器实现日志的打印，降低代码维护、迁移的成本。

结束语

위 내용은 Java 예외 처리에 대한 오해와 경험 요약에 대한 자세한 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!