我已经成为一名专业的软件工程师已有一年时间了，并持有计算机科学学位。我知道在C++和C中有关于断言的知识，但直到最近才意识到它们也存在于C#和.NET中。
我们的生产代码完全没有包含任何断言，我的问题是...
我应该开始在我们的生产代码中使用断言吗？如果是这样，在什么情况下使用最合适？或者更明智的做法是？
Debug.Assert(val != null, "message");
if ( val == null )
throw new exception("message");
PS：如果你喜欢《代码大全》，我建议你接着阅读这本书。我买这本书是为了学习如何使用WinDBG和转储文件，但前半部分充满了帮助避免错误的提示。
Debug.Assert和Trace.Assert之间的区别。后者在Release版本和Debug版本中都会被执行。 - DavidRR在代码中想要进行合理性检查以确保不变量的地方，应该随处使用Debug.Assert()。当编译发布版本（即没有DEBUG编译器常量）时，调用Debug.Assert()将被删除，因此它们不会影响性能。
在调用Debug.Assert()之前仍应抛出异常。断言只是确保在开发过程中一切都如预期。
就我个人而言，我发现我的公共方法往往使用 if () { throw; } 模式来确保方法的正确调用。而我的私有方法则倾向于使用 Debug.Assert()。
这种做法的想法是，在我的私有方法中，我自己掌控着情况，因此如果我开始使用不正确的参数调用自己的一个私有方法，那么我在某个地方打破了自己的假设——我本不应该处于那种状态。在生产环境中，这些私有断言理想情况下应该是不必要的工作，因为我应该在保持内部状态有效和一致的同时操作对象。与被任何人在运行时调用的公共方法所传递的参数相比，我仍然需要通过抛出异常来强制执行参数约束。
此外，我的私有方法在运行时仍然可能会因为某些原因（网络错误、数据访问错误、从第三方服务检索到的坏数据等）而抛出异常。我的断言只是为了确保我没有破坏关于对象状态的内部假设。
断言是在开发过程中用于检查程序运行的代码，通常是一个例程或宏。当断言为真时，这意味着一切都按预期运行。当它为假时，这意味着它已经检测到代码中的意外错误。例如，如果系统假定客户信息文件永远不会超过50,000条记录，则程序可能包含一个断言，即记录数量小于或等于50,000条。只要记录数小于或等于50,000条，该断言将保持沉默。但是，如果超过50,000条记录，它就会大声“断言”程序中存在错误。
断言在大型复杂程序和高可靠性程序中特别有用。它们使程序员能够更快地找出接口假设不匹配、代码修改时产生的错误等问题。
断言通常需要两个参数：一个描述应该为真的假设的布尔表达式和一个消息，用于在假设不为真时显示。
(…)
通常，您不希望用户在生产代码中看到断言消息；断言主要用于开发和维护过程。断言通常在开发时编译进代码，并在生产中编译出代码。在开发过程中，断言可以排除矛盾的假设、意外情况、传递给例程的错误值等。在生产环境中，它们被编译出代码，以便断言不会降低系统性能。
使用asserts检查开发人员的假设和exceptions检查环境的假设。
如果我是你，我会做：
Debug.Assert(val != null);
if ( val == null )
throw new exception();
或者为了避免重复的条件检查
if ( val == null )
{
Debug.Assert(false,"breakpoint if val== null");
throw new exception();
}
Trace.Assert代替Debug.Assert。但这会增加生产可执行文件的开销。另外，如果您的应用程序在用户界面模式下运行，默认情况下将显示Assertion对话框，这可能会让您的用户感到困惑。您可以通过删除DefaultTraceListener来覆盖此行为：请参阅MSDN中的Trace.Listeners文档。简而言之，
大量使用Debug.Assert来帮助在调试版本中捕获错误。
如果您在用户界面模式下使用Trace.Assert，可能需要删除DefaultTraceListener以避免让用户感到不安。
如果您要测试的条件是应用程序无法处理的内容，则最好抛出异常以确保执行不会继续。请注意，用户可以选择忽略断言。
断言(asserts)用于捕获程序员(你)的错误，而不是用户错误。它们仅应在用户无法引发断言时使用。例如，如果你正在编写一个API，那么在API用户可以调用的任何方法中，不应使用asserts来检查参数是否为null。但是，在未公开作为API一部分的私有方法中，可以使用它来断言当它不应该传递空参数时，YOUR代码永远不会传递null参数。
通常当我不确定时，我更喜欢使用异常(exception)而不是断言。
简而言之
Asserts（断言）用于保护和检查设计契约约束条件，即确保您的代码、对象、变量和参数状态在您预期的设计边界和限制内操作。
Asserts只应用于调试和非生产版本。在发布版本中，编译器通常会忽略Asserts。Asserts可以检查系统可控制的错误/意外情况。Asserts不是用于验证用户输入或业务规则的第一道防线。Asserts不应用于检测意外环境条件（超出代码控制范围的情况），例如：内存不足、网络故障、数据库故障等。虽然这些情况很少发生，但需要预料到（应用程序代码无法解决硬件故障或资源耗尽等问题）。通常会抛出异常，然后应用程序可以采取纠正措施（例如：重试数据库或网络操作，尝试释放缓存内存），或者如果无法处理异常，则优雅地中止。Asserts-您的代码正在意外的领域运行。堆栈跟踪和崩溃转储可用于确定出了什么问题。断言具有巨大的好处：
为了协助找到用户输入缺失的验证或高级代码中的上游错误。Debug.Assert表达了程序控制范围内其余代码块对状态所做的假设条件。这可能包括提供参数的状态、类实例成员的状态，或者方法调用的返回值是否在其合同/设计范围内。
通常，断言应该使用所有必要信息（堆栈跟踪、崩溃转储等）使线程/进程/程序崩溃，因为它们表示存在错误或未考虑的条件，这些条件没有被设计好（即不要尝试捕获或处理断言失败），唯一可能的例外是当一个断言本身可能比错误更严重时（例如，在飞行管制员需要处理飞机潜水时，他们不希望看到YSOD，尽管是否应该部署调试版本到生产中还有争议...）
何时应该使用Asserts？
Assert检查包括无效假设将导致空对象引用、零除数、数字或日期算术溢出以及一般的超出范围/不设计行为（例如，如果使用32位int来模拟人的年龄，则有必要Assert实际上年龄在0到125左右之间——-值为-100和10^10并不是设计用于此目的的）。.Net Code Contracts
在 .Net Stack 中，Code Contracts 可以被用来 作为 Debug.Assert 的补充或替代品。Code Contracts 可以进一步规范状态检查，并且可以帮助检测假设的违规情况，在编译时（或者如果在 IDE 中作为后台检查运行）之后不久就能发现。
Design by Contract (DBC) 检查包括：
Contract.Requires - 前置条件Contract.Ensures - 后置条件Invariant - 表达对象在其整个生命周期内状态的假设。Contract.Assumes - 当调用未装饰为 Contract 的方法时，安抚静态检查器。在我的看法中，大部分情况下都不需要使用Debug.Asserts。
我不喜欢的是它会让调试版本和发布版本功能有所不同。如果一个调试断言失败，但在发布版本中功能正常，这怎么说得过去呢？尤其是当负责该代码的人已经离开公司，没有人知道这部分代码时，你就必须花费时间探究问题是否真的存在。如果确实存在问题，那么为什么一开始不直接“抛出异常”呢？
对我而言，这意味着通过使用Debug.Asserts，你正在将问题推给别人去解决，而应该自己处理问题。如果某个条件应该成立，但实际上不成立，那就“抛出异常”吧。
我猜可能有一些对性能要求非常高的场景，需要优化掉Asserts，它们在那里可能会有用，但是我还没有遇到过这样的场景。
System.Diagnostics.Trace.Assert() 在发布构建和调试构建中都会执行。 - DavidRR