Debug.Assert与特定的抛出异常 [英] Debug.Assert vs. Specific Thrown Exceptions

查看:183
本文介绍了Debug.Assert与特定的抛出异常的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我刚刚开始嘲笑John Robbins的调试MS .NET 2.0应用程序,并因为Debug.Assert(...)的传播而感到困惑。



他指出,实施良好的Asserts存储状态有些错误,例如:

 调试。 Assert(i> 3,i> 3,这意味着我得到一个坏参数); 

现在,我个人觉得对我来说似乎很疯狂,他非常喜欢重新测试,业务逻辑的评论,也许i = 3必须永远不会发生,因为flobittyjam widgitification过程。



所以,我认为我得到Asserts作为一种低级别让我们保护我的假设一种事情,假设一个人觉得这只是一个测试,只需要在调试中进行,即你正在保护自己免受同事和未来的程序员的束缚,希望他们能够实际测试。



但是我没有得到的是,他接着说你应该使用断言除了正常的错误处理;现在我的设想是这样的:

  Debug.Assert(i> 3,我必须大于3,因为的脆弱状态); 
if(i< = 3)
{
throw new ArgumentOutOfRangeException(i,i must be> 3 because ... i =+ i.ToString()) ;
}

我通过Debug.Assert重复了错误条件测试获得了什么?我想我会得到它,如果我们在谈论一个非常重要的计算调试的双重检查...

  double interestAmount = loan.GetInterest(); 
Debug.Assert(debugInterestDoubleCheck(loan)== interestAmount,不匹配的兴趣calc);

...但是我没有得到参数测试,这肯定值得检查DEBUG和发布版本)...不是。我缺少什么?

解决方案

断言不用于参数检查。必须始终完成参数检查(并且准确地根据您的文档和/或规范中指定的前提条件),并根据需要抛出 ArgumentOutOfRangeException



断言用于测试不可能情况,即您(在程序逻辑中)假设的事情是真实的。这些断言是告诉你这些假设是否因任何原因而被破坏。



希望这有帮助!


I've just started skimming 'Debugging MS .Net 2.0 Applications' by John Robbins, and have become confused by his evangelism for Debug.Assert(...).

He points out that well-implemented Asserts store the state, somewhat, of an error condition, e.g.:

Debug.Assert(i > 3, "i > 3", "This means I got a bad parameter");

Now, personally, it seems crazy to me that he so loves restating his test without an actual sensible 'business logic' comment, perhaps "i <= 3 must never happen because of the flobittyjam widgitification process".

So, I think I get Asserts as a kind-of low-level "Let's protect my assumptions" kind of thing... assuming that one feels this is a test one only needs to do in debug - i.e. you are protecting yourself against colleague and future programmers, and hoping that they actually test things.

But what I don't get is, he then goes on to say that you should use assertions in addition to normal error handling; now what I envisage is something like this:

Debug.Assert(i > 3, "i must be greater than 3 because of the flibbity widgit status");
if (i <= 3)
{
    throw new ArgumentOutOfRangeException("i", "i must be > 3 because... i=" + i.ToString());
}

What have I gained by the Debug.Assert repetition of the error condition test? I think I'd get it if we were talking about debug-only double-checking of a very important calculation...

double interestAmount = loan.GetInterest();
Debug.Assert(debugInterestDoubleCheck(loan) == interestAmount, "Mismatch on interest calc");

...but I don't get it for parameter tests which are surely worth checking (in both DEBUG and Release builds)... or not. What am I missing?

解决方案

Assertions are not for parameter checking. Parameter checking should always be done (and precisely according to what pre-conditions are specified in your documentation and/or specification), and the ArgumentOutOfRangeException thrown as necessary.

Assertions are for testing for "impossible" situations, i.e., things that you (in your program logic) assume are true. The assertions are there to tell you if these assumptions are broken for any reason.

Hope this helps!

这篇关于Debug.Assert与特定的抛出异常的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆