关于异常[不断更新]

这里就不探讨C++的异常机制的复杂用法了

从个人感受上来明确一下异常抛出的时机及处理

 

一般来说遇到逻辑上的错误要么程序可以继续执行，要么该逻辑错误导致接下来无法继续。

后者毫无疑问直接抛出异常。

 

而前者是否抛出确有很多考虑

我大概总结了一些关于异常抛出的思考

 

1.如果逻辑比较底层，直接抛出。

比如你要渲染一个模型 他的mesh文件却没找到，这个时候最好直接抛出异常。

当然有的情况下，会拿其他mesh进行代替。这种作法推荐最后出版本的时候使用。

否则真正少什么资源你都不知道，很容易给搞忘记

同样不要依赖返回NULL然后进行判断

 

2.如果理论上不可发生错误的地方，直接抛出。

比如，正常操作一个数组是不会发生越界，但是谁也不知道你什么时候就给他了一个超出数组大小的下标。

在应用下标前先对下表进行判断 一旦越界就直接抛出（越界本身并不一定会导致程序崩溃，这就会导致经常碰到的随机崩溃情况）。

这条同样提醒大家对可能越界的情况多加判断。

 

3.为了调试方便，最好多记录几次异常发生地点

比如当你调用了一个接口，他刨出异常了，并且把异常记录在log文件中。这时候你在log文件里只能发现错误发生在那个接口的调用。

而那个接口却在整个工程里到处都是。这时候就进入了一个困境：明明你已经知道问题出在哪里，却不知道问题什么时候发生。如果异常信息再不够全面的话，这个异常==没有抛出。

这里推荐大家进行

try{ func();}catch(...){ Log(); throw;}

这里的catch并不是真的要对异常进行处理，只是简单记录下上层的发生位置，同时继续抛出。

这个也是深有体会，当你把编好的程序拿给别人用，再别人那里各种崩的时候，你只能通过log文件锁定错误。如果log文件不够详尽。

你只能说“你先用着，我回去看看吧。。。”

 

 

 

 

 

有的人不喜欢使用异常是觉的，明明一个小错误就导致进入如同崩溃的样子，显得不够健壮。

个人的感受是，当你和n多人一起写工程，一旦发生错误，不抛异常你是没法迅速定位问题的根源。

如果不知道什么时候该抛什么时候不该抛，有个万能的建议是 都抛了吧。。。