考虑到在有意义的地方,我们应该始终使用内置异常而不是定义我们自己的异常,即:
IllegalArgumentException
- 当方法传递无效参数时抛出,即不允许为 nullIllegalStateException
- 在不允许调用方法时抛出(即setup()
必须首先调用。当您由于用户尝试读取或写入他们无权操作的资源而引发异常时,要引发的最佳异常类型是什么(如果有)。您会推荐使用SecurityException
或吗AccessControlException
,或者这听起来毫无意义。
在我看来,两者都不是。每个异常类都有一个用途,在这种情况下SecurityException
是SecurityManager(它是 JRE 的一部分)抛出的异常类,并且AccessControlException
是SecurityException
.
我认为SecurityException
在真正的原因是未授予应用程序定义的权限(而不是由 强制执行的权限)时抛出 a 是不正确的(即使名称很漂亮SecurityManager
)。
您应该考虑到异常应该被预期能够知道如何处理它们的代码捕获。如果某些函数不知道如何“修复”异常,则应允许异常在堆栈中冒泡。任何处理的代码SecurityException
肯定不知道如何处理您的应用程序引发的异常。
从http://docs.oracle.com/javase/7/docs/api/java/security/AccessControlException.html:
此异常由 AccessController 抛出,以指示请求的访问(对关键系统资源,例如文件系统或网络)被拒绝。
拒绝访问的原因可能会有所不同。例如,请求的权限可能类型不正确、包含无效值或请求访问权限根据安全策略不允许。应尽可能在抛出异常时提供此类信息。
听起来很接近你所描述的场景。我会去的AccessControlException
。
请注意,甚至还有一个接受Permission
对象的构造函数。
我实际上建议为此用例实现您自己的(可能已检查的)异常。AFAIK 核心 API 没有任何足够通用的内容来满足您的描述。
有AccessDeniedException
,但它扩展了IOException
,因此是一个受检查的异常,并且与文件访问严格相关。
归档时间: |
|
查看次数: |
9426 次 |
最近记录: |