建议75：警惕线程不会立即启动现代的大多数操作系统都不是一个实时的操作系统，Windows系统也是如此。所以，不能奢望我们的线程能够立即启动。Windows内部会实现特殊的算法以进行线程之间的调度，在某个具体的时刻，它会决定当前应该运行哪个线程。这反映到最底层就是某个线程分配到了一定的CPU时间，可 ...
分类：
编程语言 时间：
2017-12-06 17:43:56
阅读次数：
133
建议68：从System.Exception或其他常见的基本异常中派生异常 微软建议：从System.Exception或其他常见基本异常之一派生异常。在Visual Studio中输入Exception，然后按快捷键Tab，VS会自动创建一个自定义异常类： 这是一个标准的自定义异常，它同时告诉你， ...
建议64：为循环增加Tester-Doer模式而不是将try-catch置于循环内 如果需要在循环中引发异常，你需要特别注意，应为抛出异常是一个相当影响性能的过程。应该尽量在循环当中对异常发生的一些条件进行判断，然后根据条件进行处理。 做个测试： 输出为： 796 0 以上代码中，我们预见了代码肯能 ...
建议65：总是处理未捕获的异常 处理为捕获的异常是每个应用程序具备的基本功能，C#在APPDomain提供了UnhandledException事件来接收未捕获到的异常的通知。常见的应用如下： 未捕获异常通常就是运行时期的Bug，我们可以在AppDomain.CurrentDomain.Unhand ...
建议66：正确捕获多线程中的异常 多线程的异常处理需要采用特殊的方式。一下这种方式会存在问题： 应用程序并不会在这里捕获线程的异常，而是会直接退出。从.NET2.0开始，任何线程上未处理的异常都会导致应用程序的退出（先会触发APPDomain的UnhandledException）。上面的代码中的t ...
分类：
编程语言 时间：
2017-12-06 16:14:10
阅读次数：
151
建议67：慎用自定义异常 除非有充分的理由，否则不要创建自定义异常。如果要对某类程序出错做特殊处理，那就自定义异常。需要自定义异常的理由如下： 1）方便测试。通过抛出一个自定义的异常类型实例，我们可以使捕获的代码精确的知道所发生的事情，并以符合的方式进行恢复。 2）逻辑包装。自定义异常可以包装多个其 ...
建议60：重新引发异常时使用Inner Exception 当捕获了某个异常，将其包装或重新引发异常的时候，如果其中包含了Inner Exception，则有助于程序员分析内部信息，方便代码调试。 以一个分布式系统为例，在进行远程通信的时候，可能会发生的情况肯能会有： 1）网卡被禁用或者网线断开，此 ...
建议61：避免在finally内撰写无效代码 在阐述建议之前，需要先提出一个问题：是否存在一种打破try-finally执行顺序的情况，答案是：不存在（除非应用程序本身因为某些很少出现的特殊情况在try块中退出）。应该始终认为finally内的代码会在方法return之前执行，哪怕return在tr ...
建议55：利用定制特性减少可序列化的字段 特性（attribute）可以声明式地为代码中的目标元素添加注释。运行时可以通过查询这些托管块中的元数据信息，达到改变目标元素运行时行为的目的。System.Runtime.Serialization命名空间下，有4个这样的特性： OnDeserialize ...
建议54：为无用字段标注不可序列化 序列化是指这样一种技术：把对象转变成流。相反过程，我们称为反序列化。在很多场合都需要用到这项技术。 把对象保存到本地，在下次运行程序的时候，恢复这个对象。 把对象传到网络中的另外一台终端上，然后在此终端还原这个对象。 其他场合，如：把对象赋值到系统的粘贴板中，然后 ...
