异常场景分析

异常场景分析

优质博文:IT-BLOG-CN

为了防止黑客从前台异常信息,对系统进行攻击。同时,为了提高用户体验,我们都会都抛出的异常进行拦截处理。

一、异常处理类

Java把异常当做是破坏正常流程的一个事件,当事件发生后,就会触发处理机制。Java有一套独立的异常处理机制,在遇到异常时,方法并不返回任何值(返回值属于正常流程),而是抛出一个封装了错误信息的对象

Throwable

所有的异常对象都派生于Throwable类的一个实例。在一个Throwable里面可以获取如下信息:
  ■ 获取堆栈跟踪信息。源代码中哪个类,哪个方法,第几行出现了问题……从当前代码到最底层的代码调用链都可以查出来。追踪获取底层的异常信息。
  ■ 获取没抛出来的其他Throwable。一次只能抛出一个异常,如果发生了多个异常,其他异常就不会被抛出,这时可以通过加入suppressed异常列表来解决(JDK7 以后才有)

Throwable类只有两个直接继承者:ErrorException。然后Exception又分为RuntimeExceptionCheckedException

Error

Java中, 由系统环境问题引起的异常,一般都继承于 Error 类。对于Error类:
  ■ 一般开发者不要自定义Error子类,因为它代表系统级别的错误。与一般的程序无关。
  ■ 在Java异常处理机制中,Error不强制捕获或声明,也就是不强制处理。因为程序本身对此类错误无能为力。一般情况下我们只要把堆栈跟踪信息记录下来就行。

Exception

Java中,除了系统环境问题引起的异常,一般都继承于Exception类。Exception分为RuntimeExceptionCheckedExceptionCheckedException必须要捕获或声明。而RuntimeException不强制。

CheckedException: 在Java中,直接或间接因为“资源”问题引起的异常,一般属于检查异常CheckedException。检查异常继承于Exception,而不继承于RuntimeException。对于检查异常:
  ■ 必须捕获或声明
  ■ 交给关心这个异常的方法处理
  ■ 异常处理器应该引导用户接下来怎么办,至少做到安全退出

RuntimeException: 在Java中,由于接口方法使用不当造成的异常,一般属于RuntimeException,也就是运行时异常。对于RuntimeException
  ■ 如果你调用服务方法的方式不正确,你应该马上修改代码,避免发生RuntimeException
  ■ 如果是用户方法调用你的方法的方式不正确,你应该立刻抛出RuntimeException,强制让使用者修正代码或改变使用方式,防止问题蔓延
  ■ 一般情况下,不要捕获或声明RuntimeException。因为问题在于你的程序本身有问题,如果你用异常流程处理了,反而让正常流程问题一直存在

Uncheck Exception

ErrorRuntimeException统称为非检查异常。两者的共同点就是都不被强制捕获或声明。实际上两者描述问题的范围完全没有交集。

二、Java 异常处理机制

【1】抛出异常: 当一个方法出现错误引发异常时,方法创建异常对象并交付运行时系统,异常对象中包含了异常类型异常出现时的程序状态等异常信息。运行时系统负责寻找处置异常的代码并执行。
【2】捕获异常:在方法抛出异常之后,运行时系统将转为寻找合适的异常处理器(exception handler)。潜在的异常处理器是异常发生时依次存留在调用栈中的方法的集合。当异常处理器所能处理的异常类型与方法抛出的异常类型相符时,即为合适的异常处理器。运行时系统从发生异常的方法开始,依次回查调用栈中的方法,直至找到含有合适异常处理器的方法并执行。当运行时系统遍历调用栈而未找到合适的异常处理器,则运行时系统终止。同时,意味着 Java 程序的终止。

对于运行时异常、错误或可查异常,Java 技术所要求的异常处理方式有所不同。
 ■ 由于运行时异常的不可查性,为了更合理、更容易地实现应用程序,Java 规定,运行时异常将由 Java 运行时系统自动抛出,允许应用程序忽略运行时异常。
 ■ 对于方法运行中可能出现的 Error,当运行方法不欲捕捉时,Java 允许该方法不做任何抛出声明。因为,大多数 Error 异常属于永远不能被允许发生的状况,也属于合理的应用程序不该捕捉的异常。
 ■ 对于所有的可查异常,Java 规定:一个方法必须捕捉,或者声明抛出方法之外。也就是说,当一个方法选择不捕捉可查异常时,它必须声明将抛出异常。
 ■ 能够捕捉异常的方法,需要提供相符类型的异常处理器。所捕捉的异常,可能是由于自身语句所引发并抛出的异常,也可能是由某个调用的方法或者 Java 运行时 系统等抛出的异常。也就是说,一个方法所能捕捉的异常,一定是 Java 代码在某处所抛出的异常。简单地说,异常总是先被抛出,后被捕捉的。
 ■ 任何 Java 代码都可以抛出异常,如:自己编写的代码、来自 Java 开发环境包中代码,或者 Java 运行时系统。无论是谁,都可以通过 Java 的 throw 语句抛出异常。
 ■ 从方法中抛出的任何异常都必须使用 throws 子句。捕捉异常通过 try-catch 语句或者 try-catch-finally 语句实现。

总体来说,Java 规定:对于可查异常必须捕捉、或者声明抛出。允许忽略不可查的 RuntimeException 和 Error。

捕获异常

【1】try-catch 语句:在 Java 中,异常通过 try-catch 语句结束。关键词 try 后的一对大括号将一块可能发生异常的代码包起来,称为监控区域。Java 方法在运行过程中出现异常,则创建异常对象。将异常抛出监控区域之 外,由 Java 运行时系统试图寻找匹配的 catch 子句以捕获异常。若有匹配的 catch 子句,则运行其异常处理代码,try-catch 语句结束。

匹配的原则是:如果抛出的异常对象属于 catch 子句的异常类,或者属于该异常类的子类,则认为生成的异常对象与 catch 块捕获的异常类型相匹配。

需要注意的是,一旦某个 catch 捕获到匹配的异常类型,将进入异常处理代码。一经处理结束,就意味着整个 try-catch 语句结束。其他的 catch 子句不再有匹配和捕获异常类型的机会。对于有多个 catch 子句的异常程序而言,应该尽量将捕获底层异常类的 catch 子句放在前面,同时尽量将捕获相对高层的异常类的 catch 子句放在后面。否则,捕获底层异常类的 catch 子句将可能会被屏蔽。

【2】try-catch-finally 语句:try-catch 语句还可以包括第三部分,就是 finally 子句。它表示无论是否出现异常,都应当执行的内容。

无论是否捕获或处理异常,finally 块里的语句都会被执行。当在 try 块或 catch 块中遇到 return 语句时,finally 语句块将在方法返回之前被执行。在以下 4 种特殊情况下,finally 块不会被执行:
 ■ 在 finally 语句块中发生了异常。
 ■ 在前面的代码中用了 exit()退出程序。
 ■ 程序所在的线程死亡。
 ■ 关闭 CPU。

三、全局异常处理

编写一个异常拦截类,如下:@ControllerAdvice,顾名思义,这是一个增强的Controller。使用这个Controller ,可以实现三个方面的功能:①、全局异常处理;②、全局数据绑定;③、全局数据预处理;灵活使用这三个功能,可以帮助我们简化很多工作,需要注意的是,这是SpringMVC提供的功能,在SpringBoot中可以直接使用,下面分别来看。

importcom.edu.tools.R;importorg.springframework.web.bind.annotation.ControllerAdvice;importorg.springframework.web.bind.annotation.ExceptionHandler;importorg.springframework.web.bind.annotation.ResponseBody;/** * @description: * @author: zzx * @createDate: 2020/6/2 * @version: 1.0 */@ControllerAdvicepublicclassGlobalExceptionHandler{//很重要,括号类制定需要拦截的异常,也可以进行定制化@ExceptionHandler(Exception.class)@ResponseBodypublicRerror(Exception e){ e.printStackTrace();//R表示我们给前端返回的接口格式returnR.error().message("执行全局异常处理。。。");}}

测试:

四、自定义异常处理

【1】创建自定义异常类继承RuntimeException类。

/** * @description: 自定义异常类,包含了有参合无参构造器 * @author: zzx * @createDate: 2020/6/2 * @version: 1.0 */@Data@AllArgsConstructor@NoArgsConstructorpublicclassBusinessExceptionextendsRuntimeException{privateInteger code;//状态码privateString msg;//异常消息}

【2】将自定义的异常类添加到拦截的Handler

/** * @description: * @author: zzx * @createDate: 2020/6/2 * @version: 1.0 */@ControllerAdvicepublicclassGlobalExceptionHandler{//拦截自定义异常@ExceptionHandler(BusinessException.class)@ResponseBodypublicRerror(BusinessException e){ e.printStackTrace();returnR.error().code(e.getCode()).message(e.getMsg());}}

【3】在业务代码根据需求进行手动抛出即可,业务代码展示:throw new BusinessException(20001,“手动异常抛出”);

/** * <p> * 讲师 前端控制器 * </p> * * @author zhengzhaoxiang * @since 2020-06-01 */@RestController@RequestMapping("/eduservice/edu-teacher")publicclassEduTeacherController{@AutowiredprivateEduTeacherService eduTeacherService;/** * @Description 获取所有数据 * @Author zhengzhaoxiang * @Date 2020/6/2 15:27 * @Param [] * @Return void */@GetMapping("findAll")publicRfindAll(){List<EduTeacher> list = eduTeacherService.list(null);try{int i =1/0;}catch(Exception e){//手动抛出异常thrownewBusinessException(20001,"手动异常抛出");}returnR.ok().data("items",list);}}

自定义异常处理类测试:

五、案例

某日11点23分 xxx处理中量(5s)智能检测发现异常下降60%

事后分析得知其根因是: 修改模板配置时,多配了个占位符%S导致字符串格式化的方法出错,程序未进行异常捕获,输入页加载查询接口失败,前端页面进行降级,关闭了入口,影响用户操作。

研发团队给出的解决方案:针对读取配置文案异常需要进行捕获降级,不能影响业务主流程。

案例分析

针对这类错误,以往的解决方案通常是打补丁式的修正,即:针对已发生异常的配置项进行容错处理(对解析函数添加try…catch,如上方)。

然而,每一次异常几乎都是发生在不同的配置上,也就是说我们的补丁对于生产事件的产生几乎没有任何抑制作用。补丁式修正只能治标而不能治本,我们需要一种能治本的方案。下面就让我来给大家介绍这么一种方案(如果您有更好的方案,望不吝赐教)

最佳实践

程序初始化时将所有配置读取并解析后保存为本地变量,应用每次直接读取本地Config变量。监听QConfig,当配置发生变化时调用步骤1的方法重新解析配置文件。如果解析时发生异常,记录错误日志/报警,并使用旧的配置。示例代码:

publicclassConfigStatic{privatestaticfinalLogger LOGGER =LoggerFactory.getLogger(ConfigStatic.class);privatestaticConfigStatic instance =newConfigStatic();privatestaticfinalString TITLE ="ConfigStatic";privatefinalboolean initializeSuccess;static{// 将ConfigStatic.refresh注册至ConfigurationFunc,当配置发生变化的时候ConfigStatic.refresh将被调用ConfigurationFunc.registerListener(TITLE,ConfigStatic::refresh);}privateConfigStatic(){ initializeSuccess =initialize();}publicstaticConfigStaticgetInstance(){return instance;}privatestaticvoidrefresh(){// 创建新配置(构造函数会调用initialize进行初始化)ConfigStatic newConfig =newConfigStatic();if(newConfig.initializeSuccess){// 如果新实例初始化成功,将其替换为instance instance = newConfig;}}privateSet<Integer> hsFcAddjustPriceAgencyId;// 此处省略其他配置...privatebooleaninitialize(){finalString title ="ConfigStatic.initialize";try{this.directCompareNormalAirlines =ConfigurationFunc.getHashSet("yPlusXProductConfig",",");// 此处省略其他配置...returntrue;}catch(Exception ex){LogManager.build(title, ex).error();returnfalse;}}}

Read more

OpenClaw 最新功能大揭秘!2026年最火开源AI Agent迎来史诗级升级,手机变身AI终端不是梦

OpenClaw 最新功能大揭秘!2026年最火开源AI Agent迎来史诗级升级,手机变身AI终端不是梦 大家好,我是Maynor。最近开源社区彻底炸锅了——OpenClaw(前身Clawdbot/Moltbot)又一次刷屏!这个能真正“干活”的本地AI助手,在3月2日刚刚发布v2026.3.1版本,紧接着2月底的v2026.2.26也是里程碑式更新。 从外部密钥管理、线程绑定Agent,到Android深度集成、WebSocket优先传输……OpenClaw正在把“AI常驻员工”从概念变成现实。 今天这篇图文并茂的干货,带你一口气看懂最新功能、安装上手和实战价值!

By Ne0inhk
从新加坡《Companion Guide on Securing AI Systems 》看可信AI全生命周期防护框架构建

从新加坡《Companion Guide on Securing AI Systems 》看可信AI全生命周期防护框架构建

从新加坡《AI系统安全指南配套手册》看可信AI全生命周期防护框架构建 一、引言 1.1 研究背景与意义 近年来,人工智能(AI)技术以前所未有的速度蓬勃发展,已然成为推动各行业变革与创新的核心驱动力。从医疗领域辅助疾病诊断,到金融行业的风险预测与智能投顾,再到交通领域的自动驾驶技术,AI 的身影无处不在,为社会发展带来了巨大的效益 。据国际数据公司(IDC)预测,全球 AI 市场规模在未来几年将持续保持高速增长态势,到 2025 年有望突破千亿美元大关。 然而,随着 AI 技术的广泛应用,其安全问题也逐渐浮出水面,成为制约 AI 健康发展的关键因素。AI 系统面临着来自传统网络安全威胁以及 AI 技术特有的新兴安全挑战。在传统网络安全威胁方面,诸如网络钓鱼、DDoS 攻击、恶意软件入侵等问题屡见不鲜,这些攻击手段不仅会破坏 AI 系统的正常运行,还可能导致数据泄露、隐私侵犯等严重后果。

By Ne0inhk
OpenClaw Cron 深度解读:让 AI Agent 学会自主定时工作

OpenClaw Cron 深度解读:让 AI Agent 学会自主定时工作

OpenClaw Cron 深度解读:让 AI Agent 学会自主定时工作 一句话总结:OpenClaw 的 Cron 系统让 AI Agent 具备了"设闹钟"的能力——不仅能定时提醒用户,还能自己悄悄去执行后台任务,干完活再汇报结果。 🎯 为什么 Agent 需要定时任务? 想象一下这个场景:你让 AI 助手帮你"每天早上9点检查一下服务器状态"。 传统的做法是什么?你得自己设个闹钟,到点了打开对话框,再敲一遍"帮我检查服务器"。这跟没有 AI 助手有什么区别? 真正智能的 Agent 应该能够: * 自主调度:记住用户的需求,到点自动执行 * 后台执行:不打扰用户,

By Ne0inhk
2026 AI十大趋势:木头姐《Big Ideas 2026》深度解读,解锁大加速时代的技术红利

2026 AI十大趋势:木头姐《Big Ideas 2026》深度解读,解锁大加速时代的技术红利

木头姐《Big Ideas 2026》报告指出,AI已成为撬动全球经济“大加速”的核心引擎,不再孤军奋战。本文结合报告核心数据与观点,以幽默接地气的语气,拆解2026年AI十大核心趋势,助力普通人轻松读懂技术红利。 引言 全球科技投资圈“顶流”木头姐(凯茜·伍德),带着她的十周年力作《Big Ideas 2026》如约而至!作为科技圈的“预言家手册”,这份报告每年都能精准预判行业走向,今年更是以“The Great Acceleration”(大加速)为核心,抛出震撼论断:AI早已告别“闭门造车”,成为五大创新平台的“发动机”,正引爆全球经济的变革狂欢。不同于往年聚焦单一技术,今年木头姐重点凸显AI的“全能辅助”角色——自身迭代升级的同时,还在疯狂“带飞”其他技术。接下来,我们就用最轻松的语气,拆解报告里最劲爆的AI十大趋势,

By Ne0inhk