断言在代码 - 在尝试捕捉

断言。我正在使用的代码断言验证的假设，并抛出给我很好的消息，像这样：断言在代码 - 在尝试捕捉

int IntegerDivide (int dividend , int divisor) 
{ 
    Debug.Assert (divisor != 0); 
    return (dividend/divisor); 
}

（来自为例Assertions in Managed Code）。

现在我只是想知道是否可以使用它来检查不应该抛出异常的代码。像这样的东西可以做到：

try 
{ 
    //code 
} 
catch (exceptionThatShouldntHappen ex) 
{ 
    Debug.Assert(false,"This exception should never happen!") 
}

这样做了吗？我的意思是，显然只有有例外的代码才有意义，否则它就会崩溃。但这是关键，你可以想象调用代码将会捕捉到各种各样的异常，但有些并不意味着会发生。无论调用者如何捕捉它们，您都要确保这些异常总是会中断，以免在调试中。

我会去更详细的例子：假设我有一个数据访问类类。它可以抛出各种例外。

调用代码因此会捕获异常。有时（或大多数时间？），调用代码将不会有足够的信息，或在意，可能有哪些例外。我的意思是，无论如何，失败的FindRecord（）。你赶上并返回一个错误页面或消息，甚至回退。

但在数据访问逻辑中，应该不会发生一些错误（假设文件未被发现，如果该文件被假定为在之前被检查过）。那是什么时候发生的。你断言，所以无论上游代码如何捕获异常，它在调试过程中都会中断 - 这是什么断言。

最后，如果这种做法有意义，我想知道什么是最好的方法来做到这一点。在整个地方添加try-catch必须有很大的影响（对于没有尝试捕捉的方法）。 #if DEBUG围绕try-catch看起来丑陋地狱。

来源

2016-02-02 RSinohara

虽然不同的语言，他们基本上是一样的问题。核心思想：只是忽略它 - 如果抛出异常，测试会自动失败。 –

@JeroenVannevel关键是'Debug.Assert'会导致调试器断言断言失败（处理异常通常*不*断开） – Rob

@Rob然后在调试模式下执行测试..我错过了什么吗？ –

有没有必要做try...catch，抛出的任何异常会冒出来，直到有人处理它们。

catch中的Debug.Assert只会在调试模式下引发异常。大多数情况下，您可以让调试器中断异常。

你应该对不变量使用断言，并且让其他异常被引发，直到需要处理它们。

在你的情况，我不认为你有什么想要处理异常。

这可能是更好的具体ArgumentException取代Debug.Assert，这种方式在发布模式的异常更有用，但在你的例子中，它既不在这里也不在那里。

来源

2016-02-02 23:05:23 DaveShaw

的确如此，但手头的情况恰恰是当你不想让调用代码捕获特定的异常时，因为它被假定为永远不会发生......当然，如果调用代码对于捕获什么异常一丝不苟，那会不是一个问题。 – RSinohara

但是，如果它永远不会发生，为什么要详细说明如果它发生什么应该发生？我对“这永远不会发生”的回应永远是“好的，那么我就会崩溃”。无论如何，人们立即回应“不，我们不能这样做”，在这种情况下，你知道它有时会发生，因此保证更好的处理。还要考虑大数的定律。如果你认为“这将在10000次发生1次”。如果你有一百万用户，那么很可能有100人正在遇到它。 –

断言在代码 - 在尝试捕捉

回答

相关问题