摘要：编码习惯之异常处理常识对于透传云系统或者是其他的大型系统，最怕的事情第一是系统出现了异常我不知道，等问题闹大了用户投诉了才知道出问题了。随着透传云业务流程越来越复杂，和周边子模块一堆集成，一堆的后台队列任务，任何一块都可能出问题。
编码习惯之异常处理
@(常识)
对于 透传云 系统或者是其他的大型IT系统，最怕的事情
第一是系统出现了异常我不知道，等问题闹大了用户投诉了才知道出问题了。
第二就是出了问题之后无法找到出错原因。
针对这2个问题，说说我对异常是怎么样想的和规定异常处理的。
第一个问题，系统出异常了我不知道，等技术支持问的时候才知道。
这个问题出现非常多，而且非常严重。经常会出现用户反馈、投诉过来说某个功能不可用，技术支持找的时候开发人员再定位分析之后，才发现之前的某一步出错了。随着 透传云 业务流程越来越复杂，和周边子模块一堆集成，一堆的后台队列任务，任何一块都可能出问题。
举几个例子：
技术支持：呀，透传云又传不了数据了？NB模块下发命令又发不下去了？设备怎么添加失败啊？
开发人员：好，我查一查。
开发人员A：哎哎哎，世超你看看看 API 是不是获取数据有问题啊，志远NB服务器是不是停了啊。。。。。
针对某些业务，在流程上当然可以采取相对的策略来保证，但从开发的角度来说，任何规定都无法保证一定不会发生错误，老虎也有打盹的时候，我只相信代码。
代码方面：
没事不要乱try catch 尤其是 API 异常都抛出来怎么了 一个e.getMessage包装到data数据区再加个错误码怎么了？ 直接抛到最上层用统一的全局异常处理去处理，里面做机制比如说：邮件或微信推送到开发组长和开发人员那里。（尤其是后台队列之类的操作）
新手最容易犯的错误，到处捕获异常，到处加空判断，自以为写出了“健壮”的代码，实际上完全相反。导致的问题，第一代码可读性很差，你如果工作了看到一半代码是try-catch和空判断你会同意我的观点的，第二更加重要的掩盖了很多错误，日志是不会有人看的，我们的目的是尽早让错误抛出来。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/69095.html
摘要：对变量对象或者函数等进行命名时，选择能清晰表达其用途的名字。其实，测试方法名应该明确指出测试的内容与条件。和这种命名方式是时代的前朝遗物。使用自己的异常类型笔者又一次错误地认为这一开发习惯是业内的共识。 作为 Java 开发人员，我们会遵循一系列的编码风格和开发习惯。习惯使然是一方面，另一方面，我们也从不停下脚步质疑这些习惯。一段时间以后，笔者养成了一些不同于常人的编码风格和开发习惯。...
摘要：比如面向连接的功能包发送接收数量包发送接收速率错误计数连接重连次数调用延迟连接状态等。你要处理的，就是心跳超时的逻辑，比如延迟重连。发生异常后，可以根据不同的类型选择断线重连比如一些二进制协议的编解码紊乱问题，或者调度到其他节点。 在java界，netty无疑是开发网络应用的拿手菜。你不需要太多关注复杂的nio模型和底层网络的细节，使用其丰富的接口，可以很容易的实现复杂的通讯功能。 和...
摘要：比如面向连接的功能包发送接收数量包发送接收速率错误计数连接重连次数调用延迟连接状态等。你要处理的，就是心跳超时的逻辑，比如延迟重连。发生异常后，可以根据不同的类型选择断线重连比如一些二进制协议的编解码紊乱问题，或者调度到其他节点。 在java界，netty无疑是开发网络应用的拿手菜。你不需要太多关注复杂的nio模型和底层网络的细节，使用其丰富的接口，可以很容易的实现复杂的通讯功能。 和...
摘要：文件中的代码块可用以下代码块包裹，以减少全局污染。命名规则原则尽量避免潜在命名冲突，避免过于精简，应见名知意。必须与共同使用的构造函数名应以大写字母开头。变量所有的变量必须在使用前进行声明。仅在函数和构造器内使，以明确的上下指向。 代码格式规范 1.html中外部脚本引入尽量放在尾部。 2.一个html文件中只写一个代码块。 3.JS文件中的代码块可用以下代码块包裹，以减少全局污染。 ...
阅读 2045·2021-09-26 10:21
阅读 2590·2021-09-08 09:36
阅读 2868·2019-08-30 15:56
阅读 765·2019-08-30 12:57
阅读 766·2019-08-26 10:39
阅读 3432·2019-08-23 18:11
阅读 2926·2019-08-23 17:12
阅读 834·2019-08-23 12:18
