何时使用自定义异常

时间:2011-01-17 16:06:26

标签: c# exception-handling

  

可能重复:
  Create custom exception or use built-in exceptions?

您好,

在程序设计中,为业务约束建模异常是否正常?例如。如果xyz必须> 1才能获得abc(篮子对象必须存在才能添加对象),并且篮子不存在,这是否足以让自定义异常模拟这个真实世界方案

使用自定义例外的原因是什么?

5 个答案:

答案 0 :(得分:1)

如果购物篮不存在,则听起来像ArgumentNullExceptionInvalidOperationException,具体取决于变量是否为参数。如果 xyz必须大于1 ,则听起来像ArgumentException。后一种情况听起来像你可以处理而不是依赖于验证发生地点的例外情况。

作为标准库的一部分,有许多已定义的异常。我的建议是依靠这些,直到你能清楚地证明这些例外真的不能涵盖你的特定情况。

答案 1 :(得分:1)

我认为问题不在于是否应该创建自定义异常类,而是是否应该在正常的错误输入条件下使用异常,即如果要求用户创建新密码,代码内部应该抛出PasswordTooWeakException(或者InvalidArgumentException)当密码太弱时,或者应该以另一种方式处理它。 如果这是问题,我的答案是否定的,在这种情况下你不应该使用例外。例外情况仅适用于例外情况情况,即错误情况,不会发生意外情况。

答案 2 :(得分:0)

当我计划以不同方式对待它们时,我会使用自定义异常(或者认为应该区别对待)。在许多情况下,带有良好信息的一般例外就足够了。

如果你计划在catch中做的所有事情都显示消息,那么你就不会从自定义异常中获得太多。

答案 3 :(得分:0)

大多数时候,我会推荐已经存在的异常。就像@Anthony用ArgumentException说的那样。如果需要,您可以随时在“例外”中留言。

有时,拥有自定义异常非常方便。例如,当你有这样的代码时:

catch(ArgumentException e)
{
    if(e.Message.Equals("The argument was bigger than 0"))
        // do something
    else
        // do something else
}

这会导致代码混乱,也许自定义事件或包装器异常会更合适。

也许您也可以查看此博客:http://blogs.msdn.com/b/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

答案 4 :(得分:0)

听起来您正在尝试创建复制现有异常功能的异常。例如,您的空篮子场景可以由throw new ArgumentException("Basket not instantiated");

处理

如有疑问,请回到MSDN上的Exception Design Guidelines