这真的该用try-catch吗？

前言

我有个技能，就是把“我”说的听起来特别像“老子”。

以前是小喽啰的时候，会跟领导说“我！不加班。”，听起来就像“老子不加班！”一样。到最后发现，我确实没有把计划内的工作拖到需要加班才能完成，这个“老子”也就慢慢的被承认了！到后来我带队的时候，我说“我不让你们加班！”，这个时候听起来绝对不像“老子不让你们加班！”，后来他们也真的不加班就把项目漂亮的做完了，相信他们愿意承认我有“老子”的本事。

哈哈！这个有点妄自尊大了哟。做到就可以了，千万别这么讲啊！低调，低调。不过什么事情我都能做到不加班，这事是真的。在这一系列文章里我要告诉大家一系列的实践经验，实施之后会发现：你能够一次交付了！再也不用加班了！有更多时间陪老婆孩子了！有更多时间陪哥们兄弟了！还可能有更多事情去把妹了！……总之好处多多。

本文讲述第一个原则——这真的该用try-catch吗？以后会不定期更新。

这真的该用try-catch吗？

用try-catch之前一定要三思啊！其实绝大多少情况都是不应该用try-cath的。机器的行为具有非常大的确定性，尤其是CPU，它的处理过程就是一系列的与、或、非的组合。曾经在http://bbs.pfan.cn/上看到一则广告，一个程序员研究出来成果了——机器已经具有了智能！为什么呢？机器能给出不确定的结果啊——有时候你用的操作系统、软件非常流畅好用，有时候仿佛专门使坏一样。靠！把程序的bug当人工智能，也是醉了。人才是比较“欠”的，你让他输入数字，可偏偏输入abc；你让他输入abc，他偏偏输入数字。所有欠揍的机器背后都有一群欠揍的程序员！

所以开发中要灵活处理的地方只有处理自然人跟机器交互的地方！其他地方能够约定清晰的时候尽量约定清晰，而不是依赖异常处理与恢复机制。

约定清晰说明对程序内部的行为完全掌握了，这样的代码执行效率高、好调试。换句话说代码中用的try catch越少，程序越稳健。java对错误处理只引入了异常处理机制，所以java中有两类异常checked和unchecked,unchecked本质上是错误，一个已经发布的程序原则上是不允许出现unchecked的异常的。c c++ c#等语言引入了assert机制，这种机制会使得程序遇到错误的时候直接中止执行，这种机制，错误没法隐藏。

 

能够约定清晰的时候尽量约定清晰，是为了现在不加班啊！哥们！约定清晰了，写代码的时候是不是就流畅了啊，是不是不用写那么多破坏结构的try-catch了啊！否则写代码跟便秘一样，不加班才怪呢！

 

不要用try-catch让错误隐藏起来，是为了以后不加班啊！哥们！错误隐藏起来，以后出了类似“人工智能”的错误搞死你！哭爹喊娘，找都找不到！

 

不要理解错误啊！约定清晰包括把异常也考虑进去，微软的员工写了一本书好像叫《怎么编写无错误的代码》，里面提到很多错误都在错误处理里面。异常表示什么——可能性和无法杜绝。需要考虑用异常的地方有——IO和别人的代码。IO好理解，网络通信、文件读写、数据库连接等等。别人的代码也很好理解啊——你不欠，不代表别人不欠啊。不要假定别人都是欠的哦，这样你还得考虑别人怎么欠的，多累啊。就像生活一样，不要以恶意揣摩别人，这样你将会生活在恐惧中！先假设别人不欠，等出问题了，骂他揍他都行——这事儿得你们自己负责，别说我教唆的！

 

关于这个原则，很多介绍具体实践方法的文章都提到了，这就有一篇——assert()函数用法总结。

 

发现很多只会java的或者先学java的对这个原则不能接受。哪些从汇编、C、C++一路斩上来的很容易接受这个原则。不接受不要紧，别上来就喷我！喷完喷前，还是都思考一下。