首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

在方法的末尾抛出异常--这是一种糟糕的做法吗?

在方法的末尾抛出异常是一种糟糕的做法。异常应该在方法内部被捕获和处理,而不是在方法的末尾抛出。以下是为什么这种做法是不推荐的:

  1. 可读性差:将异常抛出放在方法的末尾会使代码难以阅读和理解。开发人员通常期望方法的末尾是正常的返回点,而不是异常处理的地方。
  2. 难以维护:如果在方法的末尾抛出异常,可能会导致代码中存在大量的重复异常处理代码。这样的代码结构不仅难以维护,还会增加代码的冗余性。
  3. 可靠性差:在方法的末尾抛出异常可能会导致未处理的异常被传递到调用者的上下文中,从而导致程序崩溃或产生不可预测的行为。

相反,应该在方法内部捕获和处理异常。这样可以更好地控制异常的处理逻辑,并提供更好的错误信息和反馈给调用者。合理的做法是在方法内部使用try-catch语句块捕获异常,并根据具体情况选择合适的处理方式,例如记录日志、返回错误码或提供友好的错误提示。

总结起来,将异常抛出放在方法的末尾是一种糟糕的做法,会导致代码可读性差、难以维护和可靠性差。正确的做法是在方法内部捕获和处理异常,提供更好的错误处理和反馈机制。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

Java异常最常见八大问题

1.异常管理最佳做法 如果可以正确处理异常,则应该被捕获,否则应该抛出异常。 2.为什么try中定义变量不能用于catch或finally? 原因是你不知道try块中哪里会抛出异常。...声明对象之前抛出异常是很有可能。对于这个特定例子,这是真的。 3.为什么Double.parseDouble(null)和Integer.parseInt(null)会抛出不同异常?...他们实际上抛出不同例外 这是JDK问题。它们由不同开发人员开发,所以不值得太多思考。 4.Java中常用运行时异常 这只是其中一部分。...IllegalArgumentException ArrayIndexOutOfBoundsException 当条件不满足时,它们可用于if语句中 5.我们可以同一个catch子句中捕获多个异常?...答案是肯定。只要这些异常类可以追溯到类继承层次结构中同一个超类,就可以只使用该超类。 6.构造函数可以java中引发异常? 答案是肯定。构造函数是一种特殊方法这是一个代码示例。

37720

你如何检查参数合法性?

程度 说明 糟糕 方法会在执行过程中失败然后抛出一个不明确异常; 更糟糕 方法会正常返回,但是悄悄计算了一个错误值。...推荐做法 对公共和保护方法,使用java文档@throws标签来标注参数值不合法将抛出异常。...调用m.signum()时候这个异常被标注类级别BigInteger文档注释上,类级别的注释适用于所有的公共方法参数,这是一个避免每个方法单独文档化标注NullPointException这种混乱方法...处理list比较时候,每个对象将会跟其它对象进行比较, 如果对象不能互相比较,其中一个或多个比较会抛出ClassCastException,这是排序方法应该做。...换句话说,计算常常会抛出参数合法性检查异常,并不会匹配方法文档中申明异常。这种场景下,你应该使用异常翻译成语。转换自然异常为正确异常

1.2K10

写了挺久代码,却还被异常支配?

"t 对象为空"); 通过这样子抛出异常,排查者也能快速定位问题 我们还可以简单地把异常处理看成一种不同返回机制: ?...try 译思便是 尝试,那么是尝试做什么呢?我们知道如果在方法内部抛出异常(或者方法内调用其他方法抛出异常),这个方法将会在抛出异常过程中结束。...getMessage() 方法有点类似于 toString(),可以获取异常类更加详细信息。 栈轨迹 我们平时可以通过打 断点 方式来调试代码,跟着代码一行一行走下去,这是因为栈帧 帮组。...空 catch 块会使异常达不到应有的目的 如果我们一定要选择忽略异常,那么明确做法应该是: catch 块中包含一条注释,说明为什么可以这样做,并且将变量名称命名为 ignored 派生异常 ?...事实不是这样继承和覆盖过程中,某个特定方法"异常说明接口"不是变大了而是变小了。这相当于,我父类方法好好,被你一继承居然出现了异常,而且我还可能不知道,这不是背地里砸我招牌

55310

Java 异常面试问题与解答

Java 提供了一种健壮且面向对象方法来处理称为 Java异常处理异常情况。 1. Java中异常是什么? 异常程序执行期间可能发生错误事件,它会破坏其正常流程。...throws:当我们方法抛出任何已检查异常并且不对其进行处理时,我们需要在方法签名时使用 throws 关键字,以使调用方程序知道该方法可能抛出异常。...try-catch:我们代码中使用 try-catch 块进行异常处理。try 是块开始,catch 是 try 块末尾,用于处理异常。...我们可以有一个空 catch 块,但这是糟糕编程示例。我们永远不应该有空 catch 块,因为如果异常被该块捕获,我们将没有有关该异常信息,调试它将是一场噩梦。...这是因为 FileNotFoundException 是 IOException 子类,有两种方法可以解决此问题。 第一种方法是对两个异常都使用单个 catch 块。

91020

Python3 错误和异常

异常处理机制概述: 异常处理,是编程语言或计算机硬件里一种机制,用于处理软件或信息系统中出现异常状况(即超出程序正常执行流程某些特殊条件)。...如果需要捕捉特定异常,可以except中声明异常类型,那么这个陷阱就只能捕获你所声明异常类型,但是可以末尾写上一个通用异常陷阱,没有被特定陷阱所捕获异常最后就会被通用异常陷阱所捕获。...也可以使用此关键字代码中抛出特定异常,如果这个关键字写在except里,并且没有指定要抛出异常,那么这个raise 就会抛出这个陷阱里异常,代码示例: try:     num=10/0 except...def __init__(self, value):  # 这是初始化方法,也就是构造器             self.value = value  #这是这个类属性         def __...当创建一个模块有可能抛出多种不同异常时,一种通常做法是为这个包建立一个基础异常类,然后基于这个基础类为不同错误情况创建不同子类: class Error(Exception):     """Base

91710

教妹学 Java 第 41 讲:异常处理机制

比如说: 程序试图打开一个不存在文件; 程序遇到了网络连接问题; 用户输入了糟糕数据; 程序处理算术问题时没有考虑除数为 0 情况; 等等等等。 挑个最简单原因来说吧。...下一个问题,我经常看到一些文章里提到 Exception 和 Error,二哥你能帮我解释一下它们之间区别?”三妹问。 “这是一个好问题呀,三妹!”...checked 异常(检查型异常源代码里必须显式地捕获或者抛出,否则编译器会提示你进行相应操作;而 unchecked 异常(非检查型异常)就是所谓运行时异常,通常是可以通过编码进行规避,并不需要显式地捕获或者抛出...要么方法签名上使用 throws 关键字抛出: public class Demo1 { public static void main(String[] args) throws ClassNotFoundException...“二哥,针对 checked 异常,我知乎上看到一个帖子,说 Java 中 checked 很没有必要,这种异常在编译期要么 try-catch,要么 throws,但又不一定会出现异常,你觉得这样设计有意义

30030

LinkedList给我深深上了节for增强

想着这不是LinkedList特性,就果断使用了它。然而不久,同事反馈这个业务在读取时,时间特别长。...这是群里看见一个面试题,网上没有找到答案,我认为是基本类型和引用类型都可以,还有就是实现了Iterable接口,比如集合。有知道答案可以在下面评论下。不胜感激。...我这里就说下结论:需要循环数组结构数据时,建议使用普通for循环,因为for循环采用下标访问,需要循环链表结构数据时,一定不要使用普通for循环,这种做法糟糕,数据量大时候有可能会导致系统崩溃。...否则将会抛出 ConcurrentModificationException异常。 ?...for增强缺点 总结: 无论是在数组中还是集合中,加强型for循环都是它们各自普通for循环一种“简写方式”,即两者意思上是等价,但前者方便简单,建议多使用。

42210

Java 异常|Java Exceptions

此分类与错误异常非常相似,但在该分类中,已检查异常在恢复方面更为乐观。 检查和未检查异常 Java 中,有两种类型异常。检查 异常迫使开发人员创建处理程序异常或重新抛出它们。...这样设计意味着无法处理未经检查异常,并且注定会被抛出到顶级父级。   Java 中异常处理 有两种方法可以处理抛出异常:在当前方法中处理它或者只是重新抛出它。没有比这更好方法了。...,更改端口不不中断异常依赖线程通知中断(锁释放,另一个线程完成操作)高没有必要修复它;这是一种通知相关线程中事件方法不不另一个线程中断并使用中断通知相关中等修复另一个线程中出现问题(可以是任何东西...大多数情况下,这是正确,因为不更改代码就无法恢复应用程序。最终,运行时异常是我们坏人,它会导致新代码更改、开发人员压力和业务损失。...即使设计库情况下,您仍然可以方法签名中保留运行时异常,并在 API 中添加一些注释。在这种情况下,您 API 用户将能够决定如何处理它。

3.1K40

理解 JavaScript 中 undefined

(还有一些其他情况会抛出 ReferenceError,尤其是 ECMA 5 严格模式下运行时候。如果你有兴趣的话,可以看本文末尾阅读列表。)...如果 JavaScript 遇到无法解析引用时始终抛出 ReferenceErrors 那就更好了(实际上这是它在 ECMA 严格模式下所做)。...如果你代码写得够好的话,其实很少需要这样做。我们已经看到,典型用法中,只有一种方法可以获得不可解析引用:使用既不是属性也不是变量仅在语法上正确引用。...检查一个不可解析引用而且不抛出 ReferenceError 一种方法是使用 typeof 关键字。 if (typeof console !...幸运是,还有另一种方法:我们已经知道,如果 undefined 属性基值被定义,那么它就不会抛出 ReferenceError —— 而且由于 console 属于全局对象,我们就可以这样做: window.console

96720

猫头鹰深夜翻译:趣谈Java Exception

异常非常类似,二者区别在于程序抛出checked exception有更高几率恢复正常。...Checked 和 Unchecked异常 Checked异常强制开发者程序中进行处理或再次抛出。如果checked异常被重新抛出,则需要在方法中用throws语法声明该异常。...最乐观是Checked异常,Runtime异常相对而言可恢复可能性更小,最糟糕是Error类型异常了解了异常类型后,我们就可以试着回答以下问题: 程序当前情况有多糟糕?...问题原因是什么? 如何修复问题? 需要重启JVM? 需要重新编写代码? 熟悉异常后意味着我们可以推测程序是哪里出现了问题,并且试着修复它。...因此,我更推荐使用RuntimeException进行异常管理。即便是设计API时,也可以通过方法中定义Runtime异常加上注释辅助调用方理解。

50420

byteTCC框架--关于接口返回问题讨论

普通web项目中,调用接口返回数据,如下,不出错返回一种,出错了,返回另外一种。前端是直接可以拿到返回信息。...你可以考虑抛出一个异常啊,不过如果ByteTCCcommit/rollback处理过程中也碰到异常,以事务异常优先抛出 现在出现异常时,页面直接就这样,实际开发中,这样处理不妥啊 ?...这是ByteTCCrollback过程中也碰到异常了,抛出是SystemException 说错了,是commit过程中 HTTP接口一般返回500码就能标识错误了,当然,如果你想在应用层面设置自己业务异常码...,可以考虑用Filter拦截这个接口然后转换,直接返回字符串肯定是不可以 还是有点不懂,我们这习惯正常时返回一种编码和结果,出错时catch中返回一种编码和结果。...当然,也并不是说你controller中抛出异常就只能显示那个500了,你可以考虑框架层面对其进行处理,构建自己业务系统业务异常码,只要在全局事务之外就可以 还有2个疑问:我A调用B和C服务,

98030

try catch引发性能优化深度思考

每次 catch 执行该子句都会发生这种情况,将捕获异常对象分配给一个变量。 即使同一作用域内,此变量也不存在于脚本其他部分中。它在 catch 子句开头创建,然后子句末尾销毁。...,并且这是 JavaScript 语言一种特殊情况,所以某些浏览器不能非常有效地处理它,并且捕获异常情况下,将捕获处理程序放在性能关键循环中可能会导致性能问题,这是我们为什么上面会出现 MinorGC...事实上 plus1 和 plus2 函数代码逻辑是一致,只有代码语义是不相同,一个是返回 1,另一个是错误抛出 1,一个求和方法 try 片段完成,另一个求和方法再 catch 完成,我们可以粘贴这段代码浏览器分别去掉不同注释观察结果...上面这类代码我个人更建议写成如下形式,如果你实际上抛出并捕获了一个异常,它可能会变慢,但是由于大多数情况下上面的代码是没有异常,因此整体结果会比异常更快。...通常更合理做法回调方法通过第一个参数传递错误信息,或者考虑使用 Promise reject() 来进行处理,也可以参考 node 中常见写法如下: ?

2.6K73

【原译】javascript中错误处理

in JavaScript   这是关于JavaScript中异常处理故事。...不幸是,因为这个方法,我不知道错误是从哪个地方抛出。所以我又得反向遍历这个栈找到错误异常源头。但至少我知道某个地方出错了,并能找到是哪个地方抛出错误。...一个异常抛出同时,解释器就会从 try-catch 中离开,ajax也是一样。...这个处理函数甚至告诉我们错误是从异步代码中抛出,它告诉我们来至 setTimeout() 函数。 结论   总得来说,进行异常处理至少有两种方法。...一个是失败沉默方法错误发生时忽略错误不作为而不影响后面的继续执行。另一种是发生后迅速找到错误发生地方。明显我们知道那种方法更具有优势。我选择是:不要隐藏错误。

1.5K20

【原译】javascript中错误处理

in JavaScript 这是关于JavaScript中异常处理故事。...不幸是,因为这个方法,我不知道错误是从哪个地方抛出。所以我又得反向遍历这个栈找到错误异常源头。但至少我知道某个地方出错了,并能找到是哪个地方抛出错误。...一个异常抛出同时,解释器就会从 try-catch 中离开,ajax也是一样。...这个处理函数甚至告诉我们错误是从异步代码中抛出,它告诉我们来至 setTimeout() 函数。 结论 总得来说,进行异常处理至少有两种方法。...一个是失败沉默方法错误发生时忽略错误不作为而不影响后面的继续执行。另一种是发生后迅速找到错误发生地方。明显我们知道那种方法更具有优势。我选择是:不要隐藏错误。

2K90

Kotlin 和 Checked ExceptionKotlin 和 Checked Exception

大部分人只能在里面放一条 log,记录异常发生。这是一种非常糟糕写法,不但繁复,而且可能掩盖运行时错误。...,这种做法也就是我微软 C# 代码里经常看到。...…… 注意到了吗,这种给每个函数加上 throws Exception 或者 catch (Exception) 做法,也就是我《编程智慧》里面指出经典错误做法。...CE 只提供了一种机制,至于程序员怎么使用它,是他们自己职责。再好特性被滥用,也会产生糟糕结果。Hejlsberg 对这些问题使用了站不住脚理论。...实际上,像 Exceptional 一类 C# 静态检查工具,会要求你注释里写出可能抛出异常,这样它才能发现被忽略异常

69820

Java 编程问题:十二、`Optional`

抛出NoSuchElementException:编写一个程序,当没有值时抛出NoSuchElementException类型异常或另一个异常。...不要在设置器参数中使用Optional:举例说明设置器参数中使用Optional不良做法。 不要在方法参数中使用Optional:举例说明方法参数中使用Optional不良做法。...= ...; // this is prone to be empty return status.orElseThrow(); } 然而,要注意,在生产中抛出非受检异常而不带有意义消息是不好做法...Optional情况下,一个常见场景是为了获得一些值而链接其方法。 避免这种做法,并依赖简单和简单代码。...Optional.ofNullable(isbn); } public void setIsbn(String isbn) { this.isbn = isbn; } } 通常,这种糟糕做法

1.2K20

java 字节流入门(读文件)

程序中每一个细节都是需要注意。那么,这里为什么要有返回值? 读多少数据是我告诉这个方法,它又返回给我,这不是有病?不是。...这是什么doc,搞笑呢?但是这就是这个方法本来面目。它确实无法保证能读到你想要完整数据。...那么,有没有补救措施呢,是有的,RandomAccessFile 方法提供了另一个方法:这个方法在读到 b.length 个字节之前不会给你返回,除非遇到文件末尾或者遇到异常。...这个方法实现可以验证 乔老师猜想,(如果普通 read 方法可以保证除了遇到文件末尾,都能返回需要数据,就不需要循环读取了,只需要读一次判断 count 是否为 0 抛出异常就好了。...使用了 readFully() 方法后,我们只需要处理 EOFException(End of File Exception,读到文件末尾了还没读到要求数据长度) 一种异常就好了。

68410

try catch引发性能优化深度思考

,我电脑执行该代码时间大概是 0.2 ms 左右,这是一个比较快值,但是这里 a.replace 是正常运行,也就是 a 是一个字符串能正常运行 replace 方法,所以这里耗时是正常。...每次 catch 执行该子句都会发生这种情况,将捕获异常对象分配给一个变量。 即使同一作用域内,此变量也不存在于脚本其他部分中。它在 catch 子句开头创建,然后子句末尾销毁。...,并且这是 JavaScript 语言一种特殊情况,所以某些浏览器不能非常有效地处理它,并且捕获异常情况下,将捕获处理程序放在性能关键循环中可能会导致性能问题,这是我们为什么上面会出现 Minor...事实上 plus1 和 plus2 函数代码逻辑是一致,只有代码语义是不相同,一个是返回 1,另一个是错误抛出1,一个求和方法 try 片段完成,另一个求和方法再 catch 完成,我们可以粘贴这段代码浏览器分别去掉不同注释观察结果...通常更合理做法回调方法通过第一个参数传递错误信息,或者考虑使用 Promise reject() 来进行处理,也可以参考 node 中常见写法如下: ;(async () => {

85820
领券