检查与非检查异常
下面这句话是什么意思？
但是，对于未经检查的异常，编译器不会强制 客户端程序员要么捕获异常，要么在 抛出子句。事实上，客户端程序员甚至可能不知道 可能会抛出异常。例如，
StringIndexOutOfBoundsException由 String 的charAt()方法抛出。
根据该引用，不需要使用 try-catch 块， 但我看到编译器要求将一些代码放置在 try-catch 块中。
为什么有些异常需要 try-catch 块，而另一些则不需要？
What does the following quote mean?
With an unchecked exception, however, the compiler doesn't force
client programmers either to catch the exception or declare it in a
throws clause. In fact, client programmers may not even know that the
exception could be thrown. eg,StringIndexOutOfBoundsException
thrown by String'scharAt()method.
According to that quotation, there is no need to use try-catch blocks,
but I've seen the compiler require some code to be placed in try-catch blocks.
Why do some exceptions require try-catch blocks and others don't?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
未经检查的异常是那些扩展 RuntimeException 类的异常。编译器永远不会强迫您捕获此类异常，也不会强迫您在方法中使用 throws 关键字声明它。所有其他异常类型（不扩展 RuntimeException）都会被检查，因此必须声明为抛出和/或捕获。
当您希望方法的调用者（即 API 的用户）显式处理 API 中的异常情况时，请使用受检异常。当您相信该调用能够在该异常情况下执行一些有意义的操作（例如重试调用、回滚更改或将其转换为某些用户可读的错误消息）时，就会声明受检异常。
如果您认为该调用对异常没有任何作用（特别是当它代表错误或 API 的错误使用时），则应取消检查该异常。此外，具有太多已检查异常的 API 可能会令人厌烦地进行编程（例如，尝试使用 java 反射 API=）
Unchecked exceptions are those that extend
RuntimeExceptionclass. Compiler will never force you to catch such exception or force you to declare it in the method usingthrowskeyword. All other exception types (that do not extendRuntimeException) are checked and therefore must be declared to be thrown and/or catched.Checked exceptions are used when you want the caller of your method (i.e the user of your API) to explicitly handle the exceptional case in your API. Checked exceptions are declared when you believe the call will be able to do something meaningful with that exceptional case, like retrying the call, rolling changes back or converting it into some user-readable error message.
If you believe that there is nothing useful the call can do about the exception (especially when it represents a bug, or a wrong usage of your API), then the exception should be unchecked. Also, an API with too many checked exceptions can be annoying to program with (e.g. try using java reflection API=)
IOException。即使程序没有任何问题，这些异常也会发生。因此，有必要告诉程序如何处理异常。null对象的值时，会引发NullPointerException。因此，未经检查的异常表示需要程序员手动修复的问题。为了避免错误行为，程序崩溃是合理的，因此不需要 try-catch 块（但可能需要提供缓解措施，例如向用户显示错误）。IOExceptionthat is thrown when a file cannot be opened. These exceptions occur even if there is nothing wrong with the program. It is necessary, therefore, to tell the program how to handle the exception.NullPointerExceptionis thrown when a value is read on anullobject. Thus an Unchecked Exception represents a problem that requires a manual fix by the programmer. It is reasonable for the program to crash in order to avoid erroneous behavior, so a try-catch block is not required (but might be desirable in order to provide mitigation, such as displaying an error to the user).你的问题到底是什么？
编译器不应该（也不会）强制您尝试/捕获未经检查的异常，这将与它们的本质背道而驰。
一般的想法是，检查的异常是您可以预见的，但可能基于您无法控制且必须处理的输入。
未经检查的异常通常代表程序中的错误。
有很多人认为检查异常是 Java 平台中的一个错误，他们很少使用或根本不使用它们。您可以通过搜索谷歌了解有关这场辩论的更多信息。
What is your question exactly?
Compilers shouldn't (and won't) enforce you to try/catch unchecked exceptions, that would go against exactly what they are.
The general idea is that checked exceptions are something you may be able to foresee but may be based on input that is out of your control and that you have to deal with.
Unchecked exceptions will usually represent bugs in your program.
There's a number of people that think checked exceptions are a mistake in the Java platform and they only use them very sparingly or not at all. You can read more about this debate by searching google.
这是因为，
检查以下链接：
为什么运行时异常未被选中？
检查与非检查异常？
It is because,
Check the following links :
Why RunTime Exceptions are unchecked ?
Checked vs Unchecked Exception ?
所有异常都是运行时的一部分，而不是编译时的一部分。异常有两种类型：检查异常和非检查异常。检查异常的示例是 IO 异常、ClassNotFound 异常，非检查异常的示例是运行时异常。在检查异常的情况下，错误或警告消息在编译时出现，以便用户在运行时使用 throws 关键字来处理它，该关键字用于向默认的 catch 机制系统抛出异常。但如果出现未经检查的异常，则在编译时不会出现警告。
All Exceptions are part of run time and not compile time. There are two kinds of exceptions checked exceptions and unchecked exceptions. Examples of checked exceptions are IO Exceptions, ClassNotFound Exception and examples of unchecked exceptions are runtime exceptions. In the case of checked exceptions, error or warning message comes at compile time so that the user will take care of it at runtime by using throws keyword, which is used to throw exceptions to the default catch mechanism system. But in case of unchecked exceptions warning is not there at compile time.
**检查异常
在编写代码时要检查或处理或应该注意的异常称为检查异常。
例如：
1.我们有FileNotFoundException -->当我们编写一些与文件类相关的代码时会发生这种情况。确实有可能文件不存在。在这种情况下，为了处理它们，我们必须肯定处理这些异常。
2. 还有一个例子是ParseException，当我们处理日期函数时会发生这种情况。
未经检查的异常
这些是在编码期间可选择处理的异常。是否处理它们取决于我们。如果我们无法处理它们，则在执行过程中可能会出现运行时错误。
例如：
我们有一些称为 NullPointerException、ArithemeticException、NosSuchElementFoundException 等的异常。这些就像可选的事情，我们甚至不必处理它们。更重要的是，甚至 jvm 或编译器也不会建议我们处理它们。**
**Checked Exceptions
Exceptions which are to be checked or handled or should be taken care during the time of writing the code are called as checked exceptions.
For eg:
1. we have FileNotFoundException -->which will be occured when we are writing some code related to file classes. There will e defenetly posibility of non existence of file. In such case in order to handle them , we are forced to handle those exception for sure.
2. one more example is ParseException ,which will be occured when we are dealing with date functions.
UnChecked Exceptions
These are the exceptions that are optional to be handled during the time of coding. Its up to us whether we handle them or not. In case if we fail to handle them, There is a chance of getting runtime errors during the exceution.
For eg:
We have something called NullPointerException,ArithemeticException,NosSuchElementFoundException and so on. These are like optional things we dont even have to handle them. More over even jvm or compiler will not recommend us to handle them.**
简而言之，
即使在创建自定义异常时也使用相同的规则。
in simple words,
use the same rule even while creating your custom exceptions.