我什么时候应该使用ThrowHelper方法而不是直接投掷？

Question

什么时候使用ThrowHelper方法而不是直接投掷？

void MyMethod() {
    ...
    //throw new ArgumentNullException("paramName");
    ThrowArgumentNullException("paramName");
    ...
}
void ThrowArgumentNullException(string paramName) {
    throw new ArgumentNullException(paramName);
}

我已经读过调用一个ThrowHelper方法(一个抛出异常的唯一方法)而不是直接抛出应该产生更小的字节码.

这个以及明显的封装(另一层间接)可能是不直接抛出的好理由,至少在某些情况下是这样.

无论如何,IMO的缺点也不是没有实质性的.

• (异常)控制流程的一部分是隐藏的
• 异常最终会产生更加神秘的堆栈跟踪
• 编译器(2.0)不会识别ThrowHelper调用是方法的退出点,因此需要一些代码.

我有限的经验是整体设计经常变得更糟.

int MyMethod(int i) {
    switch (i) {
        case 1:
            return 1;
        default:
            ThrowMyException();
    }
    return 0; // Unreachable (but needed) code
 }

这可能部分是个人品味的问题.无论如何,你对这个问题有什么个人指导？您是否发现将ThrowHelpers用于所有常见任务(如方法参数验证(ThrowArgumentNullException(paramName)等)是个好主意？我在这个问题上遗漏了哪些明显的东西？

顺便说一下,我试图不将此问题与验证问题混在一起,例如:

ThrowIfNameIsNullOrEmpty(name);

Answer 1

我的默认方法是直接从异常代码分支抛出.

DRY原则和3规则引导我将它包装在一个方法中:如果我发现自己写了相同的'throw'代码3次或更多次,我考虑将它包装在一个辅助方法中.

但是,编写一个创建所需Exception然后从原始位置抛出它的Factory Method会更好,而不是抛出的方法.

public void DoStuff(string stuff)
{
    // Do something

    throw this.CreateException("Boo hiss!");
}

private MyException CreateException(string message)
{
    return new MyException(message);
}

这样可以保留堆栈跟踪.

Answer 2

这对我来说似乎是一种不必要的抽象.你有一个做一件事的方法,就像它所做的那样详细命名.

关于较少字节码的论点实际上没有意义,因为代码的大小很少重要(除非你从源代码中的一些荒谬的地方抛出异常,否则你不会为每个程序实例保存超过一千字节).与此同时,您所陈述的缺点都是真正的问题,特别是在涉及异常处理的清晰度时.

基本上抽象掉这样的小事通常会让你感到厌烦.(关于这个主题的一些有趣的阅读:http://www.joelonsoftware.com/articles/LeakyAbstractions.html)

Answer 3

我想说，唯一合理的时间是在 BCL 之类的地方，其中类的使用量足够广泛，节省的费用可能是值得的。然而，它必须是有道理的。就您而言，我认为您实际上并没有节省任何空间。BCL中ThrowHelper 的实例通过用枚举替换字符串和方法调用（以获取字符串消息）来减小大小。您的案例只是传递相同的参数，因此不会节省任何费用。调用您的方法的成本与将异常抛出到位的成本一样多。