什么时候应该在 C# 方法名称中使用“Try”？

Question

我们正在与同事讨论如果方法名称以“Try”开头意味着什么。

有以下意见：

• 当方法可以返回空值时使用“Try”。
• 当方法不会抛出异常时使用“Try”。

官方定义是什么？方法名称中的“Try”表示什么？ 有这方面的官方指南吗？

Answer 1

这称为 TryParse 模式，并已由 Microsoft 记录。 官方异常和性能 MSDN 页面说：

对于常见场景中可能抛出异常的成员，请考虑使用 TryParse 模式，以避免与异常相关的性能问题。

因此，如果您的代码的常规用例意味着它可能会抛出异常（例如解析 int），那么 TryParse 模式就有意义。

Answer 2

（已更正） 正如埃里克建议的那样，有官方指南。

当我看到

TrySomething

方法时，我就假设了

• 不扔
• 回归

  bool

• 如果我期望值，它会通过“out”参数返回
• 存在

  Something

  方法，它允许我自己处理任何异常。 （编辑，由杰西·韦伯建议）

Answer 3

我认为当你想继续时应该使用

try

。方法是否返回某个值并不重要。

情况1：如果返回正常，您可以采取某种方式继续。

情况2：如果没有返回：还可以；您可以通过其他方式继续。

如果您期望某个值作为该方法的输出，请使用

out

参数。

示例

int value
if (dictionary.TryGetValue("key", out value))
{
    // Proceed in some way
}
else
{
    // Proceed in some other way
}

Answer 4

当你想表明方法调用可能产生无效结果时，你必须在方法名称中使用“Try”。顺便说一句，遵循 .NET 标准，它不是一个引发异常的函数，而是返回一些

VALID

或

NON_VALID

（从程序角度来看，值）的函数。

最后，这就是您决定在小组中使用的命名约定。

Answer 5

请确保在方法名称中包含

try

，如果：

• 你不会抛出任何异常
• 您的方法具有以下签名：

  bool TrySomething(input, out yourReturn)

所以基本上，如果我们使用

try

方法，我们只会得到一个布尔结果。

所以下面的代码不会抛出任何异常：

string input = "blabla";
int number;
if (int.TryParse(input, out number))
{
// wooohooo we got an int!
} else
{
//dooh!
}

然而这段代码可以（并且在本例中将会）抛出异常：

string input = "blabla";
int number;
try
{
     number = int.Parse(input); //throws an exception
}
catch (Exception)
{
     //dooh!
}

使用 Try 方法是一种更安全、更具防御性的编码方式。 另外，如果代码片段 #2 不是整数，则执行时会需要更多性能。

Answer 6

当只有一个明显的失败原因时，返回指示成功的布尔值的方法只能命名为“TryX”。

说明

对此有一个有趣的倾向，我认为我们必须考虑这一点，并且我认为假设 TryParse 模式可以生成 TryX 有点牵强。 Microsoft 命名的 TryParse 模式 专门以“Parse”命名是有原因的 - 使用 'TryX' 可能 被认为是反模式，他们试图避免扩展它的使用。

如果测试者-执行者模式先测试然后执行，那么执行然后测试模式可能被称为执行者-测试者。然而，有一个根本的区别。在测试者-执行者中，执行者仍然会在失败时抛出异常。 TryX Doer-Tester 中并非如此。

这提出了一个成功坑问题。现在你的代码可能什么都不做。充其量你不知道为什么失败。在忘记 if/test 的情况下，会在代码中产生奇怪的、转移注意力的错误。

我不怕承认这是猜想。但当我第一次看到“TryParse”作为模式名称时，我想他们怎么会这么懒……然后我想也许他们不是。

使用解析时，抛出异常的原因只有一个——输入字符串的格式不正确。这样就可以理解返回值 false 的含义了。

但在一般情况下，不能这么说——可能有多种失败原因。您很快就会陷入其他最佳实践考虑因素和辩论，例如抛出异常的情况和最小化 try/catch 块和相关的日志记录。

我并不是说这种模式不被偶尔应用。我想在后台线程中以及在关闭或记录尝试期间的某些地方，如果那里出现问题，您的恢复选择就会变得很渺茫。但你真的无能为力吗？我认为这是我们在依赖既定模式之前要问的问题，该模式让我们编写可能会或可能不会做它们应该做的事情的方法。

我将以新的“尤达”规则结束。 - 做或不做，没有尝试。