4

考虑到有意义的地方，我们应该始终使用内置异常而不是定义我们自己的异常，即：

  • IllegalArgumentException- 方法传入无效参数时抛出，即不允许为null
  • IllegalStateException- 在不允许调用方法时抛出（即setup()必须先调用。

当由于用户尝试读取或写入他们无权操作的资源而引发异常时，最好的异常类型是什么（如果有的话）。你会推荐使用SecurityException or吗AccessControlException，或者这听起来没有意义。

4

5 回答 5

6

在我看来，两者都不是。每个异常类都有一个用途，在这种情况下是由SecurityManager（它是 JRE 的一部分）SecurityException抛出的异常类，并且是.AccessControlExceptionSecurityException

SecurityException我认为当真正的原因是未授予应用程序定义的权限（与 强制执行的权限相反）时抛出 a 是不正确的（即使名称很漂亮SecurityManager）。

您应该考虑到异常应该被预期能够知道如何处理它们的代码捕获。如果某些函数不知道如何“修复”异常，则应允许异常冒泡到堆栈中。任何处理的代码SecurityException肯定不知道如何处理应用程序引发的异常。

于 2013-02-27T00:23:55.410 回答
5

从http://docs.oracle.com/javase/7/docs/api/java/security/AccessControlException.html：

AccessController 抛出此异常以指示请求的访问（对关键系统资源，如文件系统或网络）被拒绝。

拒绝访问的原因可能会有所不同。例如，请求的权限可能类型不正确、包含无效值或请求根据安全策略不允许的访问。在抛出异常时，应尽可能提供此类信息。

听起来很接近你描述的场景。我会去的AccessControlException。

请注意，甚至还有一个带有Permission对象的构造函数。

于 2013-02-27T00:23:51.733 回答
2

您不应该总是使用内置异常。如果您提供 API，则抛出您自己的自定义异常更为合适，例如MyProjectPermissionException，如果您的项目是“MyProject”。IllegalArgumentException当然，在很多情况下，如果用户传入一个明显糟糕的参数，最好还是抛出一个内置函数。

您也可以考虑将实际原因，例如SecurityException，放在您自定义的异常中，如果这对您的调用者有帮助的话。

catch(SecurityException e)
{
    throw new MyProjectPermissionException("Permission denied", e);
}
于 2013-02-27T00:23:49.913 回答
0

我实际上建议为此用例实现您自己的（可能已检查）异常。AFAIK 核心 API 对您所描述的内容没有足够的概括性。

有AccessDeniedException，但它扩展IOException，因此是一个检查异常，并且与文件访问严格相关。

于 2013-02-27T00:22:33.817 回答
0

对于已检查的异常，最好使用新的异常类型。否则，如果有人抓住 a SecurityException，将不清楚它的含义。

于 2013-02-27T00:22:53.690 回答