1

假设如果我们尝试将 null 分配给某个东西，我们想抛出，那么这个技巧怎么样：

public static class ExceptionExtension
    {
        public static T Throw<T>(this Exception exc)
        {
            throw exc;
        }
    }

我们可以像这样使用：

 return possibleNull  ?? new Exception("Unspecified something....").Throw<string>();

你认为这是一个好/最差/无用的做法吗？

4

4 回答 4

5

这对我来说毫无意义 - 不是很可读。我希望??运算符的第二个参数是相同类型的possibleNull，而不是抛出异常。

我更愿意看到：

if(possibleNull == null)
{
  throw new Exception("Unspecified something....");
}

return possibleNull;
于 2011-12-16T09:39:05.887 回答
2

你总是可以把它放在某种短名称的静态助手类中：

public static class Never
{
    public static T Null<T>(T value)
        where T : class
    {
        if (value == null) throw new ArgumentNullException();
        return value;
    }
}

myClass.AProperty = Never.Null(somePotentiallyNullValue);

你的另一个例子没有多大意义，我会选择称之为“无用”的做法。

为帮助类添加一点“流畅性”往往会专注于使事情更具可读性。

http://en.wikipedia.org/wiki/Fluent_interface

于 2011-12-16T09:40:22.597 回答
2

创建某种抛出这样的静态帮助器类可能会更好，更具可读性

public static class ThrowHelper
{
    public static TException ThrowIfNull<TException>(object value)
        where TException : Exception, new()
    {
        if (value == null) //or other checks
        {
          throw new TException();
        }
    }
}
于 2011-12-16T09:46:08.033 回答
2

我不认为这是一个好习惯。

首先，扩展方法本身只是为我们已经有关键字的东西引入了一个方法：throw。这可能会令人困惑。它声明了一个返回类型，尽管它永远不会返回一个值，只是为了在你想要使用它的上下文中取悦编译器。参考其他人已经指出的，这是一个“最惊讶的原则”。

然后，看看你将如何使用这种方法，结果代码似乎不是很清楚阅读。更糟糕的是：您只能在表达式中使用这种方法，因此您总是会得到以某种方式使用对象的代码（在您的示例中：只需返回它）并在同一行中检查它是否为 null 作为副作用. 我更喜欢明确地进行空检查，而不是与其他东西混合。像CutEdge.Conditions这样的库可以帮助减少您为此输入的代码量。你会以这种方式在你的例子中使用它

Condition.Requires(possibleNull , "possibleNull ").IsNotNull();
return possibleNull;
于 2011-12-16T09:53:27.933 回答