建议67：慎用自定义异常除非有充分的理由，否则不要创建自定义异常。如果要对某类程序出错做特殊处理，那就自定义异常。需要自定义异常的理由如下：1）方便测试。通过抛出一个自定义的异常类型实例，我们可以使捕获的代码精确的知道所发生的事情，并以符合的方式进行恢复。2）逻辑包装。自定义异常可以包装多个其他异常...
建议70：避免在调用栈较低的位置记录异常并不是所有的异常都要被记录到日志，一类情况是异常发生的场景需要被记录，还有一类就是未被捕获的异常。未被捕获的异常通常被视为一个Bug，所有，对于它的记录，应该被视为系统的一个重要组成部分。最适合记录异常和报告的是应用程序的最上层，这通常是UI层。假设存在这样一...
建议66：正确捕获多线程中的异常多线程的异常处理需要采用特殊的方式。一下这种方式会存在问题： try { Thread t = new Thread((ThreadStart)delegate {...
分类：
编程语言 时间：
2015-08-18 01:06:24
阅读次数：
141
建议63：避免“吃掉”异常嵌套异常是很危险的行为，一不小心就就会将异常堆栈信息，也就是真正的Bug出处隐藏起来。这还不是最严重的，最严重的就是“吃掉”异常，即捕获，然后不向上层throw。避免“吃掉”异常，并不是说不应该“吃掉”异常，而是这里有个重要原则：该异常可被预见，并且通常情况它不能算是一个B...
建议65：总是处理未捕获的异常处理为捕获的异常是每个应用程序具备的基本功能，C#在APPDomain提供了UnhandledException事件来接收未捕获到的异常的通知。常见的应用如下： static void Main(string[] args) { ...
建议62：避免嵌套异常应该允许异常在调用堆栈上往上传，不要过多的使用catch，然后再throw。过多的使用catch会带来两个问题：1）代码更多了。这看上去好像你根本不知道怎么处理异常，所以你总是不停地catch。2）隐藏了堆栈信息，使你不知道真正发生异常的地方。无故地嵌套是我们应该极力避免的。当...
建议60：重新引发异常时使用Inner Exception当捕获了某个异常，将其包装或重新引发异常的时候，如果其中包含了Inner Exception，则有助于程序员分析内部信息，方便代码调试。以一个分布式系统为例，在进行远程通信的时候，可能会发生的情况肯能会有：1）网卡被禁用或者网线断开，此时会抛...
建议59：不要在不恰当的场合下引发异常常见的不易于引发异常的情况是对在可控范围内的输入和输出引发异常。 private void SaveUser3(User user) { if (user.Age 100) { ...
位置: 建议127: Lock与synchronized是不一样的首先在概念上纠正这一篇内容:援引Java源码中关于ReentrantLock的开篇说明:* A reentrant mutual exclusion {@link Lock} with the same basic* behavior...
分类：
编程语言 时间：
2015-08-17 09:54:41
阅读次数：
149
内功深厚的武林高手出招往往平淡无奇。同理，编程高手也不会用奇门怪招写程序。良好的编程风格是产生高质量程序的前提。 下面以C++为例，来给大家介绍。一、命名约定有不少人编程时用拼音给函数或变量命名，这样做并不能说明你很爱国，却会让用此程序的人迷糊（很多南方人不懂拼音，我就不懂）。程序中的英文一般不会太...
分类：
编程语言 时间：
2015-08-17 08:40:07
阅读次数：
119
