c++程序设计原理与实践---(2)错误？错误！

1.前置条件：

使用前置条件进行入参判断可以有效减少错误，同时，由于调用方不再需要显式对条件进行检测，这样可以有效的减少重复代码。

在使用前置条件时，为了防止函数对实现细节的相关，可以将细节参数入参传入。

注：不要相信调用者会满足你所需的条件，即使你写了厚厚的一摞手册。

2.throw：

make a objectof type xx and throw it~

try{

//code might throw exceptions

}

catch(cxceptionx& e)

{

//do something to go on the program

}

catch(...)

{

//do something to exit

}

3.后置条件

在返回值上进行判断，只返回满足条件的返回值，其他不符合条件的可以使用抛出异常等方式处理，这样可以使调用方更专注于业务逻辑，而不用再不停的判断返回值是否符合某个状态。代码更简洁，符合人类语言。

4.什么是错误

某函数实现的功能是打开一个文件，那么这个文件该如何处理文件打开失败的问题。

这是错误吗？答案是有可能是错误，也有可能不是错误。说是错误应该这样理解：我期待打开一个文件，但是文件打开出错或者失败，这时就说一个错误。说不是错误可以这样理解：我希望通过打开文件的出错或失败来作为某种状态判断等。那么这个时候，作为一个通用的打开文件的函数，该如何处理？最简单也是最靠谱的答案就是：什么也不做。作为一个底层模块，如果此时是错误，那能怎么做？文件不存在则创建一个文件？但是调用方未必希望在不存在的时候创建该文件，或者你根本没权限来创建。如果不是错误，你又能做什么？想来想去，还是什么都不做的好。这个时候，只需要把状态码返回或者异常类型返回，由调用方法处理就好。调用方根据需求写个包裹函数，比底层函数猜测一万种结果并实现处理要简单高效的多。

5.异常

写c++这种代码，还是需要对异常做处理的，但是异常怎么处理，确实是一个经验问题。但是基础的原则就是：别逞能。不该你处理或者你不能处理的东西，就不要抓，抓了你也没办法让程序退回到正常流程。抓住异常的时候一定要对关键信息记日志，以备分析。

什么时候抛异常确实是另一个跟经验有关的问题。个人感觉：在所属的层次上确实无法处理的时候，抛个异常。发生严重错误的时候，抛个异常(致命错误就直接GG了)。

====================分割线==========================

这几天看erlang，erlang的习惯是：出错就立即暴漏。果然跟c++还是有区别的啊。