百度360必应搜狗淘宝本站头条
当前位置:网站首页 > IT知识 > 正文

java安全编码指南之:异常处理(java安全编码规范3.1)

liuian 2025-06-15 17:36 6 浏览

简介

异常是java程序员无法避免的一个话题,我们会有JVM自己的异常也有应用程序的异常,对于不同的异常,我们的处理原则是不是一样的呢?

一起来看看吧。

异常简介

先上个图,看一下常见的几个异常类型。

所有的异常都来自于Throwable。Throwable有两个子类,Error和Exception。

Error通常表示的是严重错误,这些错误是不建议被catch的。

注意这里有一个例外,比如ThreadDeath也是继承自Error,但是它表示的是线程的死亡,虽然不是严重的异常,但是因为应用程序通常不会对这种异常进行catch,所以也归类到Error中。

Exception表示的是应用程序希望catch住的异常。

在Exception中有一个很特别的异常叫做RuntimeException。RuntimeException叫做运行时异常,是不需要被显示catch住的,所以也叫做unchecked Exception。而其他非RuntimeException的Exception则需要显示try catch,所以也叫做checked Exception。

不要忽略checked exceptions

我们知道checked exceptions是一定要被捕获的异常,我们在捕获异常之后通常有两种处理方式。

第一种就是按照业务逻辑处理异常,第二种就是本身并不处理异常,但是将异常再次抛出,由上层代码来处理。

如果捕获了,但是不处理,那么就是忽略checked exceptions。

接下来我们来考虑一下java中线程的中断异常。

java中有三个非常相似的方法interrupt,interrupted和isInterrupted。

isInterrupted()只会判断是否被中断,而不会清除中断状态。

interrupted()是一个类方法,调用isInterrupted(true)判断的是当前线程是否被中断。并且会清除中断状态。

前面两个是判断是否中断的方法,而interrupt()就是真正触发中断的方法。

它的工作要点有下面4点:

  1. 如果当前线程实例在调用Object类的wait(),wait(long)或wait(long,int)方法或join(),join(long),join(long,int)方法,或者在该实例中调用了Thread.sleep(long)或Thread.sleep(long,int)方法,并且正在阻塞状态中时,则其中断状态将被清除,并将收到InterruptedException。
  2. 如果此线程在InterruptibleChannel上的I / O操作中处于被阻塞状态,则该channel将被关闭,该线程的中断状态将被设置为true,并且该线程将收到java.nio.channels.ClosedByInterruptException异常。
  3. 如果此线程在java.nio.channels.Selector中处于被被阻塞状态,则将设置该线程的中断状态为true,并且它将立即从select操作中返回。
  4. 如果上面的情况都不成立,则设置中断状态为true。

看下面的例子:

    public void wrongInterrupted(){
        try{
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

上面代码中我们捕获了一个InterruptedException,但是我们仅仅是打印出了异常信息,并没有做任何操作。这样程序的表现和没有发送一异常一样,很明显是有问题的。

根据上面的介绍,我们知道,interrupted()方法会清除中断状态,所以,如果我们自身处理不了异常的情况下,需要重新调用Thread.currentThread().interrupt()重新抛出中断,由上层代码负责处理,如下所示。

    public void correctInterrupted(){
        try{
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

不要在异常中暴露敏感信息

遇到异常的时候,通常我们需要进行一定程度的日志输出,从而来定位异常。但是我们在做日志输出的时候,一定要注意不要暴露敏感信息。

下表可以看到异常信息可能会暴露的敏感信息:

除了敏感信息之外,我们还要做好日志信息的安全保护。

在处理捕获的异常时,需要恢复对象的初始状态

如果我们在处理异常的时候,修改了对象中某些字段的状态,在捕获异常的时候需要怎么处理呢?

    private int age=30;

    public void wrongRestore(){
        try{
            age=20;
            throw new IllegalStateException("custom exception!");
        }catch (IllegalStateException e){
            System.out.println("we do nothing");
        }
    }

上面的例子中,我们将age重置为20,然后抛出了异常。虽然抛出了异常,但是我们并没有重置age,最后导致age最终被修改了。

整个restore的逻辑没有处理完毕,但是我们部分修改了对象的数据,这是很危险的。

实际上,我们需要一个重置:

    public void rightRestore(){
        try{
            age=20;
            throw new IllegalStateException("custom exception!");
        }catch (IllegalStateException e){
            System.out.println("we do nothing");
            age=30;
        }
    }

不要手动完成finally block

我们在使用try-finally和try-catch-finally语句时,一定不要在finally block中使用return, break, continue或者throw语句。

为什么呢?

根据Java Language Specification(JLS)的说明,finally block一定会被执行,不管try语句中是否抛出异常。

在try-finally和try-catch-finally语句中,如果try语句中抛出了异常R,然后finally block被执行,这时候有两种情况:

  • 如果finally block正常执行,那么try语句被终止的原因是异常R。
  • 如果在finally block中抛出了异常S,那么try语句被终止的原因将会变成S。

我们举个例子:

public class FinallyUsage {

    public boolean wrongFinally(){
        try{
            throw new IllegalStateException("my exception!");
        }finally {
            System.out.println("Code comes to here!");
            return true;
        }
    }

    public boolean rightFinally(){
        try{
            throw new IllegalStateException("my exception!");
        }finally {
            System.out.println("Code comes to here!");
        }
    }

    public static void main(String[] args) {
        FinallyUsage finallyUsage=new FinallyUsage();
        finallyUsage.wrongFinally();
        finallyUsage.rightFinally();
    }
}

上面的例子中,我们定义了两个方法,一个方法中我们在finally中直接return,另一方法中,我们让finally正常执行完毕。

最终,我们可以看到wrongFinally将异常隐藏了,而rightFinally保留了try的异常。

同样的,如果我们在finally block中抛出了异常,我们一定要记得对其进行捕获,否则将会隐藏try block中的异常信息。

不要捕获NullPointerException和它的父类异常

通常来说NullPointerException表示程序代码有逻辑错误,是需要程序员来进行代码逻辑修改,从而进行修复的。

比如说加上一个null check。

不捕获NullPointerException的原因有三个。

  1. 使用null check的开销要远远小于异常捕获的开销。
  2. 如果在try block中有多个可能抛出NullPointerException的语句,我们很难定位到具体的错误语句。
  3. 最后,如果发生了NullPointerException,程序基本上不可能正常运行或者恢复,所以我们需要提前进行null check的判断。

同样的,程序也不要对NullPointerException的父类RuntimeException, Exception, or Throwable进行捕捉。

不要throw RuntimeException, Exception, or Throwable

我们抛出异常主要是为了能够找到准确的处理异常的方法,如果直接抛出RuntimeException, Exception, 或者 Throwable就会导致程序无法准确处理特定的异常。

通常来说我们需要自定义RuntimeException, Exception, 或者 Throwable的子类,通过具体的子类来区分具体的异常类型。

不要抛出未声明的checked Exception

一般来说checked Exception是需要显示catch住,或者在调用方法上使用throws做申明的。

但是我们可以通过某些手段来绕过这种限制,从而在使用checked Exception的时候不需要遵守上述规则。

当然这样做是需要避免的。我们看一个例子:

    private static Throwable throwable;

    private ThrowException() throws Throwable {
        throw throwable;
    }

    public static synchronized void undeclaredThrow(Throwable throwable) {

        ThrowException.throwable = throwable;
        try {
                ThrowException.class.newInstance();
            } catch (InstantiationException e) {
            } catch (IllegalAccessException e) {
        } finally {
            ThrowException.throwable = null;
        }
    }

上面的例子中,我们定义了一个ThrowException的private构造函数,这个构造函数会throw一个throwable,这个throwable是从方法传入的。

在undeclaredThrow方法中,我们调用了ThrowException.class.newInstance()实例化一个ThrowException实例,因为需要调用构造函数,所以会抛出传入的throwable。

因为Exception是throwable的子类,如果我们在调用的时候传入一个checked Exception,很明显,我们的代码并没有对其进行捕获:

    public static void main(String[] args) {
        ThrowException.undeclaredThrow(
                new Exception("Any checked exception"));
    }

怎么解决这个问题呢?换个思路,我们可以使用Constructor.newInstance()来替代class.newInstance()。

try {
        Constructor constructor =
                    ThrowException.class.getConstructor(new Class<?>[0]);
            constructor.newInstance();
        } catch (InstantiationException e) {
        } catch (InvocationTargetException e) {
            System.out.println("catch exception!");
        } catch (NoSuchMethodException e) {
        } catch (IllegalAccessException e) {
        } finally {
            ThrowException.throwable = null;
        }

上面的例子,我们使用Constructor的newInstance方法来创建对象的实例。和class.newInstance不同的是,这个方法会抛出InvocationTargetException异常,并且把所有的异常都封装进去。

所以,这次我们获得了一个checked Exception。

本文的代码:

learn-java-base-9-to-20/tree/master/security

本文已收录于
http://www.flydean.com/java-security-code-line-exception/

最通俗的解读,最深刻的干货,最简洁的教程,众多你不知道的小技巧等你来发现!

欢迎关注我的公众号:「程序那些事」,懂技术,更懂你!

相关推荐

面试怕被问Hashmap,多看看这个文章

o数据结构otable数组长度永远为2的幂次方o那么为什么要把数组长度设计为2的幂次方呢?o扩容o链表树化o红黑树拆分o查找o插入o删除o遍历oequasl和hashcode总结HashMap是面试中...

非常简洁地重试Retry组件,使用起来杠杠的

前言小伙伴是不是经常遇到接口调用异常,超时的场景?尤其网络抖动导致timeout超时的场景,我们一般产品就会叫我们要重试几次。很多小伙伴的实现方式是写个循环调用for(inti=1;i<=3;...

Kafka消息可靠传输之幂等、事务机制

一般而言,消息中间件的消息传输保障有3个层级,分别如下。atmostonce:至多一次。消息可能会丢失,但绝对不会重复传输。atleastonce:最少一次。消息绝不会丢失,但可能会重复传输。...

Seata源码—9.Seata XA模式的事务处理

大纲1.SeataXA分布式事务案例及AT与XA的区别2.SeataXA分布式事务案例的各模块运行流程3.Seata使用SpringBoot自动装配简化复杂配置4.全局事务注解扫描组件的自动装配...

Disruptor—3.核心源码实现分析一

大纲1.Disruptor的生产者源码分析2.Disruptor的消费者源码分析3.Disruptor的WaitStrategy等待策略分析4.Disruptor的高性能原因5.Disruptor高性...

Spring Boot 进阶-详解SpringBoot中条件注解使用

作为使用SpringBoot框架的开发者来讲,如果你连如下的这些注解你都没有听说过,没有用过,那我劝你还是放弃吧?在SpringBoot中我们最常见到的注解应该是条件注解了吧!也就是@Condit...

如何自定义编解码器(如何自定义编解码器的程序)

1.前言上一节我们一节了解了什么是编码解码、序列化和反序列化了,并且留有一道思考题,本节内容主要是深入解析该思考题。思考题:能否把我们的编码和解码封装成独立的Handler呢?那么应该如何去封装...

Disruptor—3.核心源码实现分析二

大纲1.Disruptor的生产者源码分析2.Disruptor的消费者源码分析3.Disruptor的WaitStrategy等待策略分析4.Disruptor的高性能原因5.Disruptor高性...

线程的状态有哪些?它是如何工作的?

线程的状态有哪些?它是如何工作的?线程(Thread)是并发编程的基础,也是程序执行的最小单元,它依托进程而存在。一个进程中可以包含多个线程,多线程可以共享一块内存空间和一组系统资源,因此线程之间的切...

有图解有案例,我终于把Condition的原理讲透彻了

平时加解锁都是直接使用Synchronized关键字来实现的,简单好用,为啥还要引用ReentrantLock呢?为了解决小伙伴的疑问,我们来对两者做个简单的比较吧:相同点两者都是“可重入锁”,即当前...

白话DUBBO原理,通俗易记,再也不怕面试时讲不清楚了

现在的各种面试免不了要问些中间件,尤其是互联网公司,更注重获选人对中间件的掌握情况。在中间件中,有一大类是关于RPC框架的,Dubbo即是阿里出品的一款很著名的RPC中间件,很多互联网公司都在用,面试...

Java 最细的集合类总结(java常用的集合类有哪些)

数据结构作为每一个开发者不可回避的问题,而Java对于不同的数据结构提供了非常成熟的实现,这一个又一个实现既是面试中的难点,也是工作中必不可少的工具,在此,笔者经历漫长的剖析,将其抽丝剥茧的呈现出...

详解Java异常(Exception)处理及常见异常

很多事件并非总是按照人们自己设计意愿顺利发展的,经常出现这样那样的异常情况。例如:你计划周末郊游,计划从家里出发→到达目的→游泳→烧烤→回家。但天有不测风云,当你准备烧烤时候突然天降大雨,只能终止郊...

为什么阿里强制要求不要在foreach循环里进行元素remove和add操作

在阅读《阿里巴巴Java开发手册》时,发现有一条关于在foreach循环里进行元素的remove/add操作的规约,具体内容如下:错误演示我们首先在IDEA中编写一个在foreach循...

SpringBoot条件化配置(@Conditional)全面解析与实战指南

一、条件化配置基础概念1.1什么是条件化配置条件化配置是Spring框架提供的一种基于特定条件来决定是否注册Bean或加载配置的机制。在SpringBoot中,这一机制通过@Conditional...