错误“表示合理的应用程序不应尝试捕获的严重问题”。
而
异常“表示合理的应用程序可能想要捕获的条件”。
Error 及其子类是例外。所有其他异常类都是异常。RuntimeException
unchecked
checked
检查的异常通常是程序可以从中恢复的异常,以编程方式从此类异常中恢复可能是一个好主意。示例包括 、 等。程序员应该通过使用 try-catch 块来检查这些异常,或者将其抛回给调用方。FileNotFoundException
ParseException
另一方面,我们有未经检查的异常。这些是那些异常,如果一切都井然有序,可能不会发生,但它们确实发生了。示例包括 、 等。许多应用程序将使用 或 子句 for 及其子类,但从语言的角度来看,不需要这样做。请注意,从 a 中恢复通常是可能的,但是设计类/异常的人认为最终程序员没有必要检查此类异常。ArrayIndexOutOfBoundException
ClassCastException
try-catch
throws
RuntimeExceptions
RuntimeException
错误也是未经检查的异常,程序员不需要对这些错误做任何事情。事实上,对 Errors 使用子句是一个坏主意。大多数情况下,不可能从错误中恢复,并且应该允许程序终止。示例包括 、 等。try-catch
OutOfMemoryError
StackOverflowError
请注意,尽管错误是未经检查的异常,但我们不应该尝试处理它们,但是在代码中处理(也是未检查的异常)是可以的。检查的异常应由代码处理。RuntimeExceptions
Error
并且两者都扩展了,但主要是由JVM在致命的情况下抛出的,并且应用程序无法从该错误中恢复。例如。Exception
Throwable
Error
OutOfMemoryError
虽然即使应用程序也可以引发一个,但它不是一个好的做法,相反,应用程序应该对可恢复的条件使用已检查的异常,对编程错误使用运行时异常。Error
-
-
我们是否可以直接从服务层抛出ResponsueStatusException,而不在控制器级别抛出自定义异常和处理? Spring 5 引入了 ResponseStatusException,直接从服务层抛出此异常是一种很好的做法。 案例1:
-
Java 7 update 25 使我们的 java Web 启动应用程序失败,没有日志记录 自 Oracle 推出 java 7 update 25 以来,我们的应用程序不再运行。 最初,我们收到了一些关于清单文件中缺少代码库和 sercurity 标记的警告,我们已修复。 我们现在最终遇到的问题是,在控制台中
-
好的模式?<X 扩展了异常> ...方法() 抛出 X 一些背景,然后是一些问题。 我最近才发现接口(或类)可能是其方法可能引发的(已检查)异常类型的泛型。例如: 我们调用一个泛型实用程序方法(可能在外部库中定义)来运行我们自
-