我们正在与同事讨论方法名称以 "Try" 开头的含义。
有以下两种不同的观点:
- 当方法可能返回 null 值时,请使用 "Try"。
- 当方法不会抛出异常时,请使用 "Try"。
官方定义是什么?在方法名称中,"Try" 表示什么意思?是否有一些官方指南来规范这个问题?
我们正在与同事讨论方法名称以 "Try" 开头的含义。
有以下两种不同的观点:
官方定义是什么?在方法名称中,"Try" 表示什么意思?是否有一些官方指南来规范这个问题?
这被称为TryParse模式,由微软公司进行了记录。 官方的Exceptions and Performance MSDN页面说:
考虑在常见情况下可能引发异常的成员中使用TryParse模式,以避免与异常相关的性能问题。
因此,如果您有一段代码,在常规使用情况下可能会引发异常(例如解析int),那么TryParse模式是有意义的。
ParseOrNull
和Parse
)或者甚至相反的约定(Parse
和ParseOrThrow
)也同样基础。微软指南的好处在于它促进了一致性:当你看到一个你不熟悉的代码库时,你仍然可以理解它,因为它(很可能)使用了平台所有者认可的广泛约定。 - ruakh(已更正) 有官方指南,正如Erik所建议的那样。
当我看到 TrySomething
方法时,我会假设它:
bool
Something
方法,使我能够自己处理任何异常。(编辑,由Jesse Webb建议)TryFoo
的方法,那么会有一个类似的Foo
方法,允许我自己处理任何异常。这些方法的签名可能不同,因此在没有其他代码更改的情况下,它们的用法是不能互换的。 - Jesse Webb我认为在想要继续执行时应该使用try
。无论方法是否返回某个值都没有关系。
情况1:如果它有返回值,你可以以某种方式继续进行。
情况2:如果它没有返回值,仍然可以继续以其他方式进行。
如果你期望某个方法返回一些值,则使用out
参数。
int value
if (dictionary.TryGetValue("key", out value))
{
// Proceed in some way
}
else
{
// Proceed in some other way
}
如果您的方法不会抛出任何异常,或者您的方法具有以下签名:bool TrySomething(input, out yourReturn)
,请确保在方法名称中包含try
。
因此,如果我们使用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!
}
int number = int.Parse(input);
。 - Pierre Arnaudint number;
声明以及 number = ...
赋值。 - Pierre ArnaudTryLoadFile(path, out file)
内存不足。因此,调用者期望在路径错误或访问被拒绝时不会出现错误,但是对于可能出现的更奇怪的问题,会抛出异常。并且要进行文档记录。 - Luke Puplett当您想表明方法调用可能产生无效结果时,必须在方法名中使用“Try”。按照.NET标准,这实际上不是引发异常的函数,而是从程序角度返回一些VALID
或NON_VALID
值的函数。
最后,这完全取决于您的团队决定使用的命名约定。
下面是 Uncle Bob 在他的书籍《Clean Code》中提供的一个示例。每当我们期望抛出异常时,我们可以在方法名称前使用 Try
前缀:
public void sendShutDown()
{
try{
tryToShutDown();
} catch (DeviceShutDownError e) {
logger.log(e);
}
}
然后(改编):
private void tryToShutDown()
{
//some code with no error handling, but
//something might go wrong here
}
tryToShutDown
方法不进行任何错误处理,因为这是 sendShutDown
方法的责任。
微软的 TryParse
模式违反了干净代码指南,该指南建议我们避免使用输出参数。
如果我们不是在开发 C# 的新版本,就不必坚持所有微软的指南。有时它们并不是最好的选择。