深圳建设网站公司简介,html代码基础,腾讯企业邮箱域名购买,英文网站 icp备案号“系统中每行代码#xff0c;都应该是有意义的#xff0c;如果一段代码可有可无#xff0c;那它就不应该存在。”01—内容简述异常处理是软件开发的必备技能#xff0c;但“异常处理#xff0c;究竟是处理什么#xff1f;”#xff0c;很多小伙伴并没有一个清晰的认识都应该是有意义的如果一段代码可有可无那它就不应该存在。”01—内容简述异常处理是软件开发的必备技能但“异常处理究竟是处理什么”很多小伙伴并没有一个清晰的认识大部分人的认识停留在给代码加上try/catch就算是异常处理了至于异常捕获之后该做什么并不清楚。本文阐述一下自己对异常处理的思考希望帮助大家对异常处理有一个清晰的认识在面对异常处理时能够有准确的决策。02—区分异常和错误首先要区分哪些是异常哪些是错误。可以预测可以通过代码逻辑避免发生的异常我称之为“错误”。无法预测无法通过代码逻辑避免的异常我称之为“异常”。相信到这里很多小伙伴心里已经有答案了比如平时遇到最多的——空引用异常应该算是错误这是可以通过代码逻辑避免的。而真正的异常是无法预料的比如网络中断、请求超时、堆栈溢出、第三方服务异常…等。我们区分了异常和错误那么对于属于错误的部分最佳的处理方案是通过代码逻辑尽量控制避免错误的发生而对于属于异常的部分或者遗漏的没有控制的错误该如何处理接下来便是本文的重点。03—异常处理要做什么异常处理概括起来要做三件事1.记录异常日志记录异常日志是为了后续排查定位解决异常问题需要记录的信息包括异常发生时间异常代码位置以及异常时上下文信息参数当前操作人等如果是Web请求还要记录请求的IP地址URL客户端设备信息如果是SOA或微服务架构还要记录调用链路标识TraceID。记录异常信息的原则是帮助开发人员还原异常现场快速定位异常原因以便尽快修复。2.确保非托管资源的关闭和释放包括数据库链接IO流等非托管资源的处理在发生异常的情况下如何正确关闭链接释放资源是需要重点考虑的。推荐使用 using 语句声明非托管资源而不是用try/catch可以查看我之前的文章 C# using()的本质3.处理异常后续业务逻辑主要是业务处理逻辑中事先规划的异常发生后的处理逻辑比如某个服务接口请求超时后进行重试某个功能操作失败后切换到备选方案降级或触发补偿事件在多线程中当某个子线程异常之后取消其他相关子线程操作自定义异常的处理。上述情况要根据实际的业务场景决定如果系统设计时并没有规划也就不需求去处理这部分功能。04—处理方案明确了异常处理的三件事接着看具体方案。第一件事记录异常日志毫无疑问应该由全局异常处理组件记录异常日志如果框架有全局异常处理功能就使用框架提供的异常处理功能如果框架没有那就自己开发一个。在Asp.Net中可以使用ExceptionFilter或自定义中间件实现全局异常处理。第二件事确保非托管资源关闭和释放由上文所说使用using就好。第三件事处理异常后续业务逻辑视实际业务场景而定可以在代码中加try/catch也可以开发通用的异常处理组件让业务逻辑更简洁清晰。05—总结异常处理规范建议通过代码规范尽量减少系统中可控的异常错误发生。通过全局异常组件记录异常日志处理通用异常。仅在业务逻辑明确需求的情况下使用try/catch处理异常。06—成长轨迹有小伙伴习惯在每个方法中都加try/catch却说不清为何这么做大概的理由是程序总难免会报错所以要进行try/catch。根本原因在于对代码运行机制不够理解对自己的代码没有信心以及对异常处理认识的模糊。这些try/catch是不应该出现的会对代码简洁性可读性造成污染与优雅代码背道而驰。我自己也是从这个阶段过来的也希望小伙伴们不要一直停留在这个阶段。我第一次对异常处理有深刻认知是得到了一位微软首席架构师的指点这位架构师是沈征一位大师级的技术专家既能讲理论画架构图又能写出优雅的框架代码是我多年职业生涯中遇到的为数不多的大师他的几句话足以让人在迷雾之中看清前方的路看见远方的山看到头顶的太阳和蓝天再次向大师致敬。认为内容有价值的话可以点赞转发关注
