在处理可能失败的功能时，最佳做法是什么？ [英] What is best practice when it comes to handling functions that can fail?
问题描述
所以，假设我有一个失败的功能。由于复杂性（即访问某些资源和验证内容或其他内容），因此不适合使用Contract.Requires处理所有内容。然而，函数体会发现所有可能的意外错误
并将它们包装在适当的例外中。
So, lets say I have a function that can fail. Due to complexity (i.e. accessing some resource and validating contents or something) it is not suitable to handle everything with Contract.Requires. The function body however finds all possible unexpected errors and wraps them in suitable exceptions.
public string Unreliable(string someInput)
{
Contract.Requires(someBasicChecks);
...
if(somethingbad) throw new YouDidBadBecauseException(...);
...
return result;
}
基本上我知道该函数将：
So basically I know that the function will either:
1）失败需要。
2）抛出异常。
3）成功
现在有很多地方都在调用此功能。我一直期待成功。如果抛出异常，则环境出现问题，因此我希望Unreliable（）抛出的异常传播到顶部。
Now there are a lot of places calling this function. I always expect a success. If an exception is thrown, something is wrong with the environment, so I want the exception thrown by Unreliable() to propagate to the top.
我称之为函数的所有地方都会对代码合同感到烦恼，并抱怨它可能会返回null。
Code contract will be annoyed by all the places I call this function and complain that it might return null.
使用的代码很多地方：
var result = Unreliable（param）;
var result = Unreliable(param);
DoSomethingWith（result）;
DoSomethingWith(result);
处理这些警告的最佳做法是什么？
What is the best practice to handle these warnings?
我可以要么：
1）在任何地方改变我的代码到处使用Unreliable（）：
1) Alter my code like this everywhere Unreliable() is used:
var result = Unreliable(param);
Contract.Assume(result != null);
DoSomethingWith(result);
因为我知道我会崩溃或者在这里有值。这样做的缺点是我会收到很多合同。随处可见。
since I know that I will either crash or have a value here. The downside with this is that I will be getting a lot of Contract.Assume cluttered everywhere.
2） 添加合同。确保（结果！= null）为不可靠。这是真的，我永远不会返回null，但我可能会抛出异常，如果捕获将导致值未设置。这很好，因为它显示了我对
调用者的意图，他们应该信任这个值，如果失败则不要尝试/捕获它。但它闻起来很烂，因为它也给出了错误的假设，我保证给出答案。
2) Add Contract.Ensures(result != null) to Unreliable. This is sort of true, I will never return null, but I might throw an exception, which if caught will result in the value not being set. This is nice because it sort of shows my intention to the callers that they should trust this value, and not try/catch it if it fails. But it smells rotten since it also gives false presumptions that I guarantee an answer.
3）降低我的警告水平/删除警告输入？
3) Reduce my warning levels/remove warnings of type?
4）在任何地方添加支票我使用代码来满足分析器：
4) Adding a check everywhere I use the code to satisfy the analyzer:
var result = Unreliable(param);
if(result != null)
{
DoSomethingWith(result);
}
这项检查似乎很愚蠢，因为我永远不会在这里使用空值。
This check however seems stupid because I will never get here with a null value.
5）尝试/接听我的电话不可靠（）
5) Try/catching my calls to unreliable()
string result = null;
try
{
result = Unreliable(param);
}
catch(SomeException e) {... }
if(result != null)
{
DoSomethingWith(result);
}
6）一些好的建议？
任何人都知道如何最好地处理代码合同中不可靠的方法，谁可以给我一个提示？
Anyone knows how to best handle unreliable methods in Code Contracts, who can give me a hint?
/ K
推荐答案
嗨Kjell，
Hi Kjell,
使用选项＃2：将Contract.Ensures（结果！= null）添加到不可靠。
Use option #2: Add Contract.Ensures(result != null) to Unreliable.
确保表示仅在方法时适用的后置条件退出，没有例外。 如果您想添加仅在方法引发异常时适用的后置条件，那么您将使用 EnsuresOnThrow
代替。
Ensures represents a post-condition that only applies when the method exits without an exception. If you wanted to add a post-condition that only applies when the method throws an exception, then you would use EnsuresOnThrow instead.
- Dave
这篇关于在处理可能失败的功能时，最佳做法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
