异常是否应该总是公开?

4

我知道始终将异常序列化是一件好事。但是它们是否应该始终是public的呢?即使它们只应该在内部捕获?如果异常不是public,是否可能存在安全问题或序列化问题(例如跨应用程序域的封送)。

4个回答

4

但是该页面表示,如果“您确定异常仅在私下使用”,则可以抑制该规则,这也是OP的主张的一部分。 - Sven
不完全是这样的:cause子句表示“非公共异常直接派生自Exception、SystemException或ApplicationException。” - Vlad

4
事实上,如果内部异常不是接口的一部分,那么它们并没有什么坏处。这意味着:
- 要么异常绝对不能越过模块的边界, - 要么您提供一个公共基本异常,供您模块的用户捕获。
实际上,为您的模块声明一个公共基本异常类型是个好主意,这样您的用户在他们的 catch 子句中总是可以依赖它。从基类派生的各个异常可以是公共的(如果您愿意),但也可能不是。
请注意,您绝对不能依赖公共/私有机制来确保任何形式的安全性,因为它可以轻松地用纯反射覆盖。

0

这与任何作用域的范围相同。所有内容都应该在适当的作用域内。

如果您在特定类中创建异常,并且仅在类内部使用该异常,则它应该仅在类内部具有作用域,因此应该是私有的。但是,这种情况并不常见。

一旦您有一个将传递给调用您的类的另一个对象的异常,您应该将其设置为公共。这是异常的最常见用法,因此大多数异常应该是公共的。


0
考虑一下这个问题... 异常会传递到多高的层级?如果一个异常将从一个公共函数中抛出,那么它本身应该是公共的。
话虽如此,如果异常总是在您的库中捕获并且永远不会被抛出或重新标记为其他异常抛出,则可以将其设置为内部。
理想情况下,我希望有这种情况:
namespace MyAPI
{
    public class PublicException : System.Exception
    {
    }

    // derive my public exceptions from this
    public class CatchableException : PublicException
    {
    }

    // stuff that should never reach the users of my API
    internal class InvisibleException : System.Exception
    {
    }
}

这样,我的API的用户就有一个捕获我抛出的任何异常的工具。内部异常永远不会到达那里。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接