摘要：
建议66：正确捕获多线程中的异常多线程的异常处理需要采用特殊的方式。一下这种方式会存在问题： try { Thread t = new Thread((ThreadStart)delegate {... 阅读全文
摘要：
建议65：总是处理未捕获的异常处理为捕获的异常是每个应用程序具备的基本功能，C#在APPDomain提供了UnhandledException事件来接收未捕获到的异常的通知。常见的应用如下： static void Main(string[] args) { ... 阅读全文
摘要：
建议64：为循环增加Tester-Doer模式而不是将try-catch置于循环内如果需要在循环中引发异常，你需要特别注意，应为抛出异常是一个相当影响性能的过程。应该尽量在循环当中对异常发生的一些条件进行判断，然后根据条件进行处理。做个测试： Stopwatch watch =... 阅读全文
摘要：
建议63：避免“吃掉”异常嵌套异常是很危险的行为，一不小心就就会将异常堆栈信息，也就是真正的Bug出处隐藏起来。这还不是最严重的，最严重的就是“吃掉”异常，即捕获，然后不向上层throw。避免“吃掉”异常，并不是说不应该“吃掉”异常，而是这里有个重要原则：该异常可被预见，并且通常情况它不能算是一个B... 阅读全文
摘要：
建议62：避免嵌套异常应该允许异常在调用堆栈上往上传，不要过多的使用catch，然后再throw。过多的使用catch会带来两个问题：1）代码更多了。这看上去好像你根本不知道怎么处理异常，所以你总是不停地catch。2）隐藏了堆栈信息，使你不知道真正发生异常的地方。无故地嵌套是我们应该极力避免的。当... 阅读全文
摘要：
建议61：避免在finally内撰写无效代码在阐述建议之前，需要先提出一个问题：是否存在一种打破try-finally执行顺序的情况，答案是：不存在（除非应用程序本身因为某些很少出现的特殊情况在try块中退出）。应该始终认为finally内的代码会在方法return之前执行，哪怕return在try... 阅读全文
摘要：
建议60：重新引发异常时使用Inner Exception当捕获了某个异常，将其包装或重新引发异常的时候，如果其中包含了Inner Exception，则有助于程序员分析内部信息，方便代码调试。以一个分布式系统为例，在进行远程通信的时候，可能会发生的情况肯能会有：1）网卡被禁用或者网线断开，此时会抛... 阅读全文
摘要：
建议59：不要在不恰当的场合下引发异常常见的不易于引发异常的情况是对在可控范围内的输入和输出引发异常。 private void SaveUser3(User user) { if (user.Age 100) { ... 阅读全文
摘要：
建议58：用抛出异常代替返回错误代码CLR异常机制的优点：正常控制流会被立即中止，无效值或状态不会在系统中继续传播。提供了统一的处理错误的方法。提供了在构造函数、操作符重载及属性中报告异常的遍历机制。提供了异常堆栈，便于开发者定位异常发生的位置。不应该将异常机制用于正常控制流中，异常的发生是一个小概... 阅读全文
摘要：
建议57：实现ISerializable的子类型应负责父类的序列化我们将要实现的继承自ISerializable的类型Employee有一个父类Person，假设Person没有实现序列化，而现在子类Employee却需要满足序列化的场景。不过序列化器并没有默认处理Person类型对象，这些事情只能... 阅读全文
摘要：
建议56：使用继承ISerializable接口更灵活地控制序列化过程接口ISerializable的意义在于，如果特性Serializable，以及与其像配套的OnDeserializedAttribute、OnDeserializingAttribute、OnSerializedAttribut... 阅读全文
摘要：
建议55：利用定制特性减少可序列化的字段特性（attribute）可以声明式地为代码中的目标元素添加注释。运行时可以通过查询这些托管块中的元数据信息，达到改变目标元素运行时行为的目的。System.Runtime.Serialization命名空间下，有4个这样的特性：OnDeserializedA... 阅读全文
摘要：
建议54：为无用字段标注不可序列化序列化是指这样一种技术：把对象转变成流。相反过程，我们称为反序列化。在很多场合都需要用到这项技术。把对象保存到本地，在下次运行程序的时候，恢复这个对象。把对象传到网络中的另外一台终端上，然后在此终端还原这个对象。其他场合，如：把对象赋值到系统的粘贴板中，然后用快捷键... 阅读全文