4

我最近一直在考虑按合同设计,我想知道人们认为在 .NET 中断言值的前置条件和后置条件的最佳方式是什么?即验证方法的参数值。

有些人推荐 Debug.Assert,而其他人则谈论使用 if 语句加上抛出异常。各自的优缺点是什么?

您推荐了哪些可用的框架?

4

5 回答 5

3

另一种选择是Spec#

Spec# 是面向对象语言 C# 的扩展。它扩展了类型系统以包括非空类型和检查异常。它以前置条件和后置条件以及对象不变量的形式提供方法契约。

于 2008-10-01T05:36:37.743 回答
3

当 .NET 4.0 发布时,我们最终会使用代码契约。但是,现在在我们的生产代码中,我们已经通过“Guard”类以及生成异常的常用方法取得了巨大的成功。

有关更多详细信息,请参阅我关于此的帖子

于 2009-05-21T02:27:52.127 回答
1

我更喜欢异常而不是断言,因为如果它应该是那样而不是那样,我想知道它以便我可以修复它,并且我们在调试模式下获得的覆盖范围远不及现实生活中的使用或覆盖范围,所以只是使用 Debug.Assert 还不够。

使用断言意味着您不会在发布代码中添加臃肿,但这意味着您只有在调试构建中捕获它们时才能看到这些合约何时以及为什么会被破坏。

使用异常意味着无论何时发生、调试或发布,您都可以看到合约中断,但这也意味着您的发布版本包含更多检查和代码。

您可以采用中间方法并使用 Trace 将您的前置条件和后置条件追踪到某种应用程序日志,您可以使用这些日志来调试问题。但是,您需要一种收集这些日志的方法,以了解您的用户遇到了什么问题。也有可能将此与异常结合起来,这样您就可以获得更严重问题的异常。

不过,我的看法是,如果合同值得执行,那么当它违反时抛出异常是值得的。我认为这在某种程度上取决于意见和目标应用程序。如果您确实抛出异常,您可能需要某种形式的事件报告系统,该系统在引发的异常未处理时提供崩溃报告。

于 2008-09-30T22:48:58.893 回答
1

您可以在http://conditions.codeplex.com/上查看 fluent 框架, 它是开源且免费的。

于 2011-02-01T00:57:31.573 回答
0

Spec# 是实现它的方法,它是 C# 的超集。现在你有了“代码契约”,它是 Spec# 的与语言无关的版本,所以现在你可以在 VB.NET 中拥有代码契约。

于 2009-05-21T02:16:31.010 回答