Something About Assert()——C#中的断言

如何尽早地发现Bug，提高软件质量的文章。看到了断言技术，感觉断言是每个程序员必备的基本功。可以让程序中的Bug在离其发生地最近的地方被断言发现，防止Bug的蔓延。 
　　在.NET中的断言的使用，是使用System.Dig.Debug。断言一般是在程序处于Debug模式下，才起作用。而可以在程序发布时（即Release模式），编译器会采用条件编译，将断言从Release版本的dll中去掉。 
　　该使用断言几种使用场景，如： 
１、方法参数的合法性 
２、对于非法情况进行断言而对于错误情况不断言且必须处理 
３、对于任何假定进行断言 
４、用断言对程序开发环境（OS/Compiler/Hardware   ）的假设进行检查 
５、编写防错程序，然后在处理错误之后可用断言宣布发生错误（一般对于Switch语句中的default进行断言） 
６、用断言保证没有定义的特性或功能不被使用（如果原先规定的一部分功能尚未实现，应进行断言）。 
　　这些断言的使用场景，我都同意。不过，我有以下几个疑问： 
１、对于第一条，由于断言会在程序的Release版本中由编译器自动去掉，那么往往我们开发一个基本库，public、protected修饰的方法怎么能保证调用者输入的参数的合法性呢（当然如果是调用者使用的是Debug版本的程序那是没有什么问题）。 
２、我们将程序发布给用户，即使我们在开发过程中使用了断言，可以大大提高程序的质量，但是难免程序中仍然有Bug。那么用户在使用Release版本的程序时，如果程序出现Bug，我们怎么才能像调试阶段一样，在离Bug出生地最近的地方，发现它呢？我目前，只认为可以将程序出现的异常，在程序的最上层，捕获所有的异常，并将异常信息及堆栈信息作为日志保存下来。但是这个时候，我们还是难以定位这个Bug，因为其出生地已经难以定位了