如果你希望强制你的类调用者来处理异常，那么就用Checked Exception；如果你不希望强制你的类调用者来处理异常，就用UnChecked。...；而下面两个异常是和业务逻辑相关的流程，从业务实现的角度来说，类调用者必须处理，所以要Checked，强迫调用者去处理。...在这里将用户验证和密码验证转化为方法返回值是一个非常糟糕的设计，不但不能够有效的标示业务逻辑的各种流程，而且失去了强制类调用者去处理的安全保障。...至于类调用者catch到NoSuchUserException和PasswordNotMatchException怎么处理，也要根据他自己具体的业务逻辑了。...或者他有能力也应该处理，就自己处理掉了；或者他不关心这个异常，也不希望上面的类调用者关心，就转化为RuntimeException；或者他希望上面的类调用者处理，而不是自己处理，就转化为本层的异常继续往上抛出来
笔者推荐三本经典的书籍《代码整洁之道 》、《编写可读代码的艺术》、《重构:改善既有代码的设计》，下文重点将从注释、命名、方法、异常、单元测试等多个方面总结了一些代码整洁最佳实践，大部分是笔者总结于以上三本书中的精华...； 某个公共函数调用的私有函数紧随其后； 最理想的参数是零参数，最长不要超过三个入参，尽量不要输出参数： 如果函数传入三个及以上参数最好将其抽象为类； 标识参数十分丑陋，向函数传入布尔值用于区分不同业务的做法很丑陋...，应该把他们放在一起，而且调用者应该放在被调用者上面； 自上向下展示函数调用依赖顺序； 应该把解释条件意图的函数抽离出来，尽可能将条件表达为肯定形式； 不要继承常量，比如接口中定义常量，不要使用继承欺骗编程语言的作用范围规则...； 类中的方法越少越好，函数知道的变量越少越好，类拥有的实体变量越少越好； 通过减少变量的数量和让他们尽量“轻量级”来让代码更有可读性： 减少变量； 缩小变量的作用域； 只写一次的变量更好，如常量； 最好读的代码就是没有代码...； 尽可能减少类和方法的数量； 以上规则按重要程度排列； 无论是设计系统或者单独模块，别忘了使用大概可工作的最简单方案； 整洁的代码只提供一种而非多种做一件事的途径，他只有尽量少的依赖。
以上从一种角度对这些主要的异常类进行了分类，其实我们还有一种分类方式，按照是否是检查类异常(checked)进行分类，什么是检查类异常？...RuntimeException，属于unchecked异常，由输出的结果可以看出：main方法中调用方法doMaths();，于是进入该方法内部，执行int a = 10/0;产生异常，在本方法中未找到处理...我们使用关键字throws将本程序中可能遇到的异常向上抛出（向调用出抛出，让调用者处理），而本身不做处理。...，这个叫异常的声明表示本方法不处理这个异常，谁调用我这个方法谁来处理（后面将讨论如何处理异常，因为总要有人来处理，否则就默认打印异常信息），可以声明多个异常，异常之间使用逗号相隔。 ...s处可能出现异常，就可以主动抛出异常*/ 小结一下，throws关键字表示：本函数中存在某个异常但是我不知道，如果出现此异常就抛给调用者。
； 某个公共函数调用的私有函数紧随其后； 最理想的参数是零参数，最长不要超过三个入参，尽量不要输出参数： 如果函数传入三个及以上参数最好将其抽象为类； 标识参数十分丑陋，向函数传入布尔值用于区分不同业务的做法很丑陋...，应该把他们放在一起，而且调用者应该放在被调用者上面； 自上向下展示函数调用依赖顺序； 应该把解释条件意图的函数抽离出来，尽可能将条件表达为肯定形式； 不要继承常量，比如接口中定义常量，不要使用继承欺骗编程语言的作用范围规则...obj)，现代编译器对if(obj = null)这样的代码会给出警告； 一般情况使用if else，简单语句使用三目运算符； 通常来讲提早返回可以减少嵌套并让代码整洁； 八、设计 类应该足够短小：...； 类中的方法越少越好，函数知道的变量越少越好，类拥有的实体变量越少越好； 通过减少变量的数量和让他们尽量“轻量级”来让代码更有可读性： 减少变量； 缩小变量的作用域； 只写一次的变量更好，如常量； 最好读的代码就是没有代码...； 尽可能减少类和方法的数量； 以上规则按重要程度排列； 无论是设计系统或者单独模块，别忘了使用大概可工作的最简单方案； 整洁的代码只提供一种而非多种做一件事的途径，他只有尽量少的依赖。
在Java中还提供了另一种异常处理方式即抛出异常，顾名思义，也就是说一旦发生异常，我把这个异常抛出去，让调用者去进行处理，自己不进行具体的处理，此时需要用到throw和throws关键字。 ...如果声明抛出的异常是运行时异常，此方法可以用try..catch进行异常捕获处理，也可以不捕获，此方法无需使用throws声明抛出；此方法的调用者可以选择地进行异常捕获处理，也可不捕获处理，同样也可以不使用...如果抛出的异常对象是运行时异常，此方法可以用try..catch进行异常捕获处理，也可以不捕获，此方法无需使用throws声明抛出；此方法的调用者可以选择地进行异常捕获处理也可不捕获处理，同样也可以不使用...把底层的原始异常直接传给用户是一种不负责任的表现，通常的做法是：程序先捕获原始异常，然后抛出一个新的业务异常，新的业务异常中包含了对用户的提示信息，这种处理方式呗称为异常转译。...八、异常链（异常转译） 把底层的原始异常直接传给用户是一种不负责任的表现，通常的做法是：程序先捕获原始异常，然后抛出一个新的业务异常，新的业务异常中包含了对用户的提示信息，这种处理方式呗称为异常转译。
试想业务组件中有两类互相依赖的变化因素，这两类变化分别有M和N种可能性。那么最糟糕的情况下，我们需要完成M*N个编程CASE来完成对M*N中可能性的覆盖。这显然是很糟糕的。...3）桥接模式的落地方法： 将两类变化因素分别进行抽象，以某个变化因素抽象为调用方，另外一个变化因素抽象为被调用方，尽量将两类因素间的依赖关系在抽象中描述。...3）策略模式的落地方法： 针对多实现方法的算法或者业务模块，对其接口做抽象，调用者依赖抽象。...而组合模式，使得对象的组合/聚合关系可以被外部自由的改变。 其二，组合模式也可以视为类的递归(VS 函数递归)。要描述递归的过程或者结构，组合模式为我们提供了用类进行描述的方法。...调用者可以按需自由灵活的进行功能的组合。 其二，装饰者模式在语法层面和组合模式非常像，在语法上可以视为一种特殊的组合模式。然而在概念意义上，装饰者模式和组合模式是截然不同的。
一旦你选择了进行处理异常，也就意味着你承认问题的发生，采用必要要的措施去让应用程序从错误中恢复，从而让业务继续进行，阻止应用程序崩溃。 ?...Exception(异常)和Error(错误)的共性和区别：两者都可以被捕捉，但前者可以被应用程序本身处理，后者是严重的，是无法恢复处理的。 ?...，不熟悉你代码的同事或者几个月之后的你，可能需要调用你这些方法并进行异常处理，所以尽可能多的提供信息，让你的API更容易理解，比如能用NumberFormatException就不要用 IllegalArgumentException...这条最佳实践和前面两条有点相似，但这条提供的信息不单是给方法调用者看的，而更多的是为了给记录日志或监控工具提供的，便于排查异常。...try { new Long("xyz"); } catch (NumberFormatException e) { log.error(e); throw e; } 直观的感觉是记录异常，然后抛出异常让调用者可以恰当的处理
然而，对于每一种正确设计 API 的方法，通常都有几十种不正确的设计方法。简单地说，创建一个糟糕的 API 非常容易，而创建一个好的 API 则比较困难。...异常会迫使调用方处理错误。另一种情况，调用者可能查找一个变量，如果没有则替换一个默认值。如果是这样的话，抛出异常完全是错误的，因为处理异常会破坏正常的控制流，而且比测试 null 或空返回值更困难。...获得可用 API 的一个好方法是让调用者编写函数名，并将该API签名交给程序员来实现。仅这一步就至少消除了一半糟糕的API，如果API的实现者从不使用他们自己的API，这对可用性会造成灾难性的后果。...某些系统调用会被中断，迫使程序员明确处理并手动重启被中断的系统调用，而不是让内核透明地处理。 推卸责任可以采取许多不同的形式，各种 API 的细节差别很大。...另一方面，如果调用者编写文档，调用者可以从用户的角度处理问题，不受当前实现的影响。这使得 API 更有可能满足调用者的需求，并防止许多设计缺陷的出现。
想想下面的例子（不好的做法！）...然后 await authorModel.fetch(authorId) 被调用。...如果你想让调用者处理它，你可以直接抛出普通的错误对象，如 throw errorr，它允许你在 promise 链中使用 async getBooksByAuthorWithAwait() 函数(也就是说...如果不需要每步执行错误处理，你仍然可以在一个 try ... catch 块中包装多个 await 调用来处理一个地方的错误。 这种方法也有一个缺陷。...有时这可能是致命的:如果 BookModel 被包含在一系列函数调用中，其中一个调用者吞噬了错误，那么就很难找到这样一个未定义的错误。 让函数返回两个值 另一种错误处理方法是受到Go语言的启发。
当我们要重构一个类时，尤其是要重构该类的方法时，往往需要事先确定待重构的方法究竟有多少调用依赖。一旦该方法被多个类调用时，重构接口就成了一件非常棘手的工作。...整个重构加重写的过程如下所示： 从外部调用者发现它依赖的类 创建新的类，然后仅将当前外部调用者需要调用的方法原封不动地搬移到新类中 在调用者内部的调用点，将旧类替换为新类，并保证功能正确 编写对应的测试覆盖该功能...该方法是我们需要修改的目标。现在，我们反其道而行之，在外部定位一个面向某个业务发起调用的类，如针对航空器位置业务的一个类AircraftProcessor，它的调用关系如下所示： ?...图中标记为灰色的类，就是我本希望重构的类，然而根据前面的分析，它们都有多处调用者，要进行重构，就可能牵一发动全身，要做到改变现有代码的结构而不破坏其功能，就好比做一台精密的脑颅手术一般，难度非常大。...为此，我们选择的做法是定义一个新的AircraftRepository类，并站在调用者AircraftLocationPreFilter的角度，将它需要的方法原封不动地拷贝到新类中，并在调用者内部以新类替换对旧类的调用
使用依赖注入，不仅可以为Bean注入普通的属性值，还可以注入其他Bean的引用。依赖注入是一种优秀的解耦方式，其可以让Bean以配置文件组织在一起，而不是以硬编码的方式耦合在一起。...当某个Java对象（调用者）需要调用另一个Java对象（被依赖对象）的方法时，在传统模式下通常有两种做法： 原始做法: 调用者主动创建被依赖对象，然后再调用被依赖对象的方法； 简单工厂模式: 调用者先找到被依赖对象的工厂...注意上面的主动二字，这必然会导致调用者与被依赖对象实现类的硬编码耦合，非常不利于项目升级的维护。...使用Spring框架之后，调用者无需主动获取被依赖对象，调用者只要被动接受Spring容器为调用者的成员变量赋值即可，由此可见，使用Spring后，调用者获取被依赖对象的方式由原来的主动获取，变成了被动接受...子元素让Spring为调用者Bean的实现类实现指定的抽象方法Notes； Spring会采用运行时动态增强的方式来实现<lookup-method...
异常机制可以使程序中的异常处理代码和正常业务代码分离 ，保证程序代码更加优雅，并可以提高程序的健壮性 。...通常的做法是:程序先捕获原始异常， 然后抛出一个新的业务异常， 新的业务异常中包含了对用户的提示信息， 这种处理方式被称为异常转译。...， 首先传给该方法的调用者， 该方法调用者再次传给其调用者……直至最后传到 main 方法， 如果 main 方法依然没有处理该异常， JVM 会中止该程序， 并打印异常的跟踪栈信息。...接下来跟踪栈记录程序中所有的异常发生点， 各行显示被调用方法中执行的停止位置， 并标明类、类中的方法名、 与故障点对应的文件的行。...一行行地往下看， 跟踪栈总是最内部的被调用方法逐渐上传，直到最外部业务操作的起点， 通常就是程序的入口 main 方法或 Thread 类的 rim 方法（ 多线程的情形）。
Exception 类以及它的子类，代表程序运行时发送的各种不期望发生的时间。可以被 Java 异常 处理机制使用，是异常处理的核心。..."t 对象为空")； 通过这样子抛出异常，排查者也能快速的定位问题 我们还可以简单地把异常处理看成一种不同的返回机制： ?...异常捕获 在编写代码处理异常时，对于检查异常，有2种不同的处理方式：使用try…catch…finally语句块处理它；或者在函数签名中使用throws声明交给函数调用者去解决。...通过抛出受检异常，我们应该在一个 catch 子句中处理该异常，或者将它传播出去，让调用者处理。 ? 运行时异常 和 错误 都属于 非受检可抛出结构。它们都是不需要也不应该被捕获的可抛出结构。...图中 Dog 类继承于 Animal 类，重写了 eat() 方法。当时在我们打算抛出异常的时候，却发现编译器提示报错。纳闷的同时，怀疑了一下这编译器是不是坏了？
那随着这样的请求越来越多，最终啊，服务a内部的资源一定会被耗尽，那整个服务a等于也就出现故障了。 那按照这样一种方式去发展，最终整个集群是不是就挂了？这就是雪崩问题。 那线程隔离的做法比较简单啊。...这是线程隔离和熔断它的一个原理，那在这呢，我们会发现啊。 无论是线程隔离还是熔断，其实都是对服务调用者的一种保护，避免服务的调用者被故障服务给拖垮。...对吧，那我服务a依赖于服务c呀，你挂了，结果把我拖垮了，这不行，所以我要保护这个调用者。 那要保护服务的调用者是不是应该在微服务发起远程调用的时候去做隔离或者熔断呀。...你咔抛个异常到前端，那前端会以为你这出了什么事呢，给用户的感受就不够好，那比较好的一种处理方案是什么呢？ 第一种办法，我们可以给用户返回一个友好提示，告诉他说啊诶，这里出了些什么事。...那么信号量啊，它不会去创建独立线程，而会去使用你原始的这个处理请求的线程，而让你直接去调用Feign的客户端去调用服务c。 那它怎么去做隔离呢？
throws 处理try...catch外还可以使用 throws来处理异常，在方法上使用 throws关键字可以声明该方法可能抛出的异常 // 可以 throws声明一哥异常，也可以声明多个 public...这里其实就可以体现出throws的作用了 那就是我不想处理这个异常时，我可以把问题往外抛，谁调用我谁就来处理，就好像在工作中出现了一个问题：你可以选择将这个问题自行解决，也可以将这个问题丢给你的上级解决...正常的业务流程要求，不允许null值出现，可如果调用者传递了一个null值进来。 此时我们该怎么做呢？...= "默认值"; } // ...继续执行业务逻辑 } // 就好像你非法进入一个地方，保安发现了你，不光没赶你走还贴心地给了你一个身份牌，让你可以继续前行 第二种做法就是直接结束方法...如果问题能够解决，并且你也愿意解决，那就让逻辑继续执行 如果问题无法解决，或者你不愿解决，但又不至于抛哥异常给调用者，就可以直接结束方法 如果问题非常严重，严重到需要警告调用者，就可以抛出异常
再结合CTRL+C和CTRL+V 绝世秘籍，一个个功能点便如同雨后春笋般被快速克隆实现。 是不是有种雄霸天下的感觉，管他什么业务场景，大爷我一梭到底，天下无敌！！！ ? 可现实真的是这样？...简单的做法是在UserService类中增加一个joinProject()方法 又过了几天，业务方又提了一个需求，统计一个用户参加过多少个项目，我们是不是又在UserService类中增加一个countProject...实现思路： 子类可以实现父类的抽象方法 子类中可以增加自己特有的方法。 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。...一个接口只服务于一个子模块或业务逻辑。 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。 结合业务，因地制宜。...但这样会带来一个安全隐患，如果该方法被普通权限的业务方误调用，容易导致误删用户，引发灾难。
AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦,提高代码的灵活性和可扩展性， AOP可以说也是这种目标的一种实现。...利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低， 提高程序的可重用性，同时提高了开发的效率。 主要功能 日志记录，性能统计，安全控制，事务处理，异常处理等等。...主要意图 将日志记录，性能统计，安全控制，事务处理，异常处理等代码从业务逻辑代码中划分出来，通过对这些行为的分离， 我们希望可以将它们独立到非指导业务逻辑的方法中，进而改变这些行为的时候不影响业务逻辑的代码...举几个例子 你的程序写好了。现在发现要针对所有业务操作添加一个日志，或者在前面加一道权限控制，怎么办呢？ 传统的做法是，改造每个业务方法。这样势必把代码弄得一团糟。而且以后再扩展还是更乱。...于是就有了切面的概念，我将方法注入到接口调用的某个地方（切点）。 第3版 这样接口只需要关心具体的业务，而不需要关注其他非该接口关注的逻辑或处理。 红框处，就是面向切面编程。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
腾讯会议
云直播
对象存储
