到目前为止,我已经做了一年的专业软件工程师,并获得了计算机科学学位。我知道c++和C中的断言有一段时间了,但直到最近才知道它们存在于c#和。net中。
我们的生产代码不包含任何断言,我的问题是这个…
我应该开始在我们的生产代码中使用断言吗?如果可以,什么时候使用它最合适?这样做会更有意义吗
Debug.Assert(val != null, "message");
or
if ( val == null )
throw new exception("message");
到目前为止,我已经做了一年的专业软件工程师,并获得了计算机科学学位。我知道c++和C中的断言有一段时间了,但直到最近才知道它们存在于c#和。net中。
我们的生产代码不包含任何断言,我的问题是这个…
我应该开始在我们的生产代码中使用断言吗?如果可以,什么时候使用它最合适?这样做会更有意义吗
Debug.Assert(val != null, "message");
or
if ( val == null )
throw new exception("message");
当前回答
在我的书里几乎从来没有。 在绝大多数情况下,如果你想检查一切是否正常,那么就扔掉。
我不喜欢的是,它使调试构建在功能上与发布构建不同。如果调试断言失败,但功能在发布中工作,那么这有什么意义呢?如果断言者早已离开公司,没有人知道这部分代码,那就更好了。然后你就得花点时间去探索这个问题,看看它是不是真的是个问题。如果这是一个问题,那为什么那个人不第一时间扔呢?
对我来说,这建议使用调试。声称你把问题推给别人,自己解决问题。如果某件事应该是这样,但事实并非如此,那就扔掉。
我猜可能有一些性能关键的场景,你想要优化你的断言,它们在那里很有用,但是我还没有遇到这样的场景。
其他回答
如果您希望在生产代码中使用断言(即发布构建),您可以使用Trace。Assert而不是Debug.Assert。
这当然会增加生产可执行文件的开销。
此外,如果您的应用程序在用户界面模式下运行,则默认情况下将显示断言对话框,这可能会让您的用户感到不安。
您可以通过删除DefaultTraceListener来覆盖这种行为:查看Trace的文档。MSDN中的侦听器。
总之,
使用调试。自由断言,以帮助在调试版本中捕获错误。 如果你使用Trace。在用户界面模式下断言,您可能希望删除DefaultTraceListener以避免让用户感到不安。 如果你测试的条件是你的应用程序无法处理的,你可能最好抛出一个异常,以确保执行不会继续。请注意,用户可以选择忽略断言。
断言用于捕获程序员(您的)错误,而不是用户错误。只有在用户不可能触发断言时才应该使用它们。例如,如果你正在编写一个API,在API用户调用的任何方法中,都不应该使用断言来检查参数是否为空。但是它可以在一个私有方法中使用,而不是作为API的一部分公开,以断言您的代码永远不会在不应该传递null参数时传递null参数。
当我不确定时,我通常更喜欢异常而不是断言。
就其价值而言……我发现我的公共方法倾向于使用if () {throw;}模式,以确保方法被正确调用。我的私有方法倾向于使用Debug.Assert()。
The idea is that with my private methods, I'm the one under control, so if I start calling one of my own private methods with parameters that are incorrect, then I've broken my own assumption somewhere--I should have never gotten into that state. In production, these private asserts should ideally be unnecessary work since I am supposed to be keeping my internal state valid and consistent. Contrast with parameters given to public methods, which could be called by anyone at runtime: I still need to enforce parameter constraints there by throwing exceptions.
此外,如果某些东西在运行时不起作用(网络错误、数据访问错误、从第三方服务检索的坏数据等),我的私有方法仍然可以抛出异常。我的断言只是为了确保我没有破坏我自己关于对象状态的内部假设。
我不会在产品代码中使用它们。抛出异常,捕获和记录。
在asp.net中也需要小心,因为断言可以显示在控制台上并冻结请求。
所有的断言应该是代码,可以优化为:
Debug.Assert(true);
因为它检验的是你已经假设为真的东西。例如:
public static void ConsumeEnumeration<T>(this IEnumerable<T> source)
{
if(source != null)
using(var en = source.GetEnumerator())
RunThroughEnumerator(en);
}
public static T GetFirstAndConsume<T>(this IEnumerable<T> source)
{
if(source == null)
throw new ArgumentNullException("source");
using(var en = source.GetEnumerator())
{
if(!en.MoveNext())
throw new InvalidOperationException("Empty sequence");
T ret = en.Current;
RunThroughEnumerator(en);
return ret;
}
}
private static void RunThroughEnumerator<T>(IEnumerator<T> en)
{
Debug.Assert(en != null);
while(en.MoveNext());
}
在上面,有三种不同的空参数方法。第一个接受它为允许的(它只是什么都不做)。第二个则抛出异常供调用代码处理(或不处理,导致错误消息)。第三种假设它不可能发生,并断言它是这样的。
在第一种情况下,没有问题。
在第二种情况下,调用代码有一个问题——它不应该用null调用GetFirstAndConsume,所以它会返回一个异常。
在第三种情况下,这段代码有一个问题,因为在调用它之前,它应该已经检查过en != null,所以它不是真的是一个错误。或者换句话说,它应该是理论上可以优化为Debug.Assert(true)的代码,sicne en != null应该始终为真!