java - 为什么只能在方法签名中将某些异常声明为抛出

Question

当声明带有“IllegalAccessException”的方法时 eclipse 迫使我
将方法声明为抛出异常

public void a()  throws IllegalAccessException {
 if(x == 1){
   throw new IllegalAccessException("TEST);
 }
}

在使用“IllegalStateException”的方法 b 中，我不需要将该方法声明为抛出异常

public void b()  {
 if(x == 1){
   throw new IllegalStateException("TEST);
 }
}

你的异常有什么不同
那个强制我声明抛出异常的方法
另一个不是

谢谢你

Answer 1

因为 IllegalAccessException 不是 RuntimeException(即检查异常)，而 IllegalStateException 是 RuntimeException(即未检查异常)。
阅读本文了解更多信息:Difference between java.lang.RuntimeException and java.lang.Exception
Oracle 网站上的这个解释:http://download.oracle.com/javase/tutorial/essential/exceptions/catchOrDeclare.html

The first kind of exception is the checked exception. These are exceptional conditions that a well-written application should anticipate and recover from. For example, suppose an application prompts a user for an input file name, then opens the file by passing the name to the constructor for java.io.FileReader. Normally, the user provides the name of an existing, readable file, so the construction of the FileReader object succeeds, and the execution of the application proceeds normally. But sometimes the user supplies the name of a nonexistent file, and the constructor throws java.io.FileNotFoundException. A well-written program will catch this exception and notify the user of the mistake, possibly prompting for a corrected file name. Checked exceptions are subject to the Catch or Specify Requirement. All exceptions are checked exceptions, except for those indicated by Error, RuntimeException, and their subclasses.

The second kind of exception is the error. These are exceptional conditions that are external to the application, and that the application usually cannot anticipate or recover from. For example, suppose that an application successfully opens a file for input, but is unable to read the file because of a hardware or system malfunction. The unsuccessful read will throw java.io.IOError. An application might choose to catch this exception, in order to notify the user of the problem — but it also might make sense for the program to print a stack trace and exit.

Errors are not subject to the Catch or Specify Requirement. Errors are those exceptions indicated by Error and its subclasses.

The third kind of exception is the runtime exception. These are exceptional conditions that are internal to the application, and that the application usually cannot anticipate or recover from. These usually indicate programming bugs, such as logic errors or improper use of an API. For example, consider the application described previously that passes a file name to the constructor for FileReader. If a logic error causes a null to be passed to the constructor, the constructor will throw NullPointerException. The application can catch this exception, but it probably makes more sense to eliminate the bug that caused the exception to occur.

Runtime exceptions are not subject to the Catch or Specify Requirement. Runtime exceptions are those indicated by RuntimeException and its subclasses.