1

我正在遵循Fail Fast原则。我想知道有一个 Assertion 类来检查我的构造函数参数参数是否是一种好习惯。

例如：

public static class Assertions
{
    public static void ParamterIsNotNull(object subject, string paramName = "")
    {
        if (subject == null) throw new ArgumentNullException(paramName, "Paramter cannot be null");
    }
}

并在使用中：

public class Test
{
    public Test(object obj)
    {
        Assertions.ParamterIsNotNull(obj, "obj");
    }
}

这是将异常抛出到另一个类的好习惯，还是直接在构造函数中抛出异常更好？

4

1 回答 1

1

从我读到的内容（在文章的末尾），马丁说两件事都做很好 - 快速失败，提供有意义的异常和“缓慢失败” - 让用户能够联系支持并继续不论异常都能成功完成的任务。

在这种情况下，批处理系统示例非常好 - 尽管批处理中的一项可能失败，但用户很可能希望处理其余的，这就是为什么你抛出一个被全局处理程序（全局处理程序）捕获的异常处理程序决定继续下一项并汇总错误，以便将其显示给用户并向开发团队发送通知）。

这样两者都完成了——大部分用户的工作都完成了，快速失败原则也被触发了。

所以这取决于你的具体情况——也许如果你的类参与其他操作，会有更多的全局类（或使用它的调用者类）能够更好地决定它是否可以继续。

另一方面 - 你的类不应该能够判断调用类是否可以在失败的情况下做一些其他的工作，所以你需要在构造函数中抛出你的异常，是的。这就是我的想法 - 是的:)。因此，如果您的类代表批次中的一个项目 - 调用者很可能会捕获异常并继续。如果它是某种入口点类 - 那么您可能想要优雅地处理异常（或根本不抛出它），向用户显示错误消息并提供详细信息（日志）以便开发团队能够轻松告知问题出在哪里。

于 2011-12-04T07:17:50.900 回答