隐式异常也不要显示的忽略吧，至少记录一条日志，不然会造成异常黑洞。之前帮同事找一个线上小概率问题，所有的日志和异常检测都抓不到，最后对全部进程一起strace，才发现是他catch了异常，啥都没做就return了... 我们后来揍了丫的

@ stone扎西华丹，是我给极客时间出难题了，我的好些文章里有好多代码，有的会有好些图片，有的会有好些数学公式，这类文章不但都非常难配上语音，而且可能在手机端的排版都会很有问题，难为极客时间的编辑、产品和技术了，这个还望能理解了（后面的文章这样的事你会看到很多）

期望听您对进程、线程、多进程、多线程的讲解，谢谢！

“错误处理”真的是一个在实践中既简单又不简单的事情。说他简单呢，是因为，每个人在学写代码的时候都会学到一些错误处理的方法： * 检查一个系统提供给你的错误码，这种我只在 C Bash里碰到过 * 返回码，各种语言都可以 * 多返回值 go python 都可以 * try catch finally 最具代表性的Java 不论哪种处理方法，其实学习的时候都不会觉得很难理解，讲解这类问题的章节也比较短。说这事不简单是因为放到实践中问题就多了： * 资源回收。这个问题是在C语言里必须妥善处理的问题，到了C++，有了对象其实已经有了很好的解决 * 返回码是否可忽略。只要你是可以忽略的，那么人类的本性就会by default的把它忽略，不管你是系统的错误码，还是那种函数直接返回的错误码。这种在 Java 里解决的比较好，你不能隐式忽略exception的存在。 * 错误返回码 vs 异常捕捉 到底用哪个？ 最后这个问题确实有争议，博主的首先观点是**“不希望发生的用异常捕捉，可能会发生的用返回码”**。但我站在业务中工程实践的角度来说有些不一样的理解。“不希望发生的事”，有的是你能处理的了的，有的是你处理不了的。对于你能处理的了的，你（不管用什么方式）能检测到并应加以处理就可以了，对于你处理不了的，你除了抛异常似乎也没什么办法了；“可能发生的”也分你能处理的了的，和你处理不了的。比如说，你自己维护了一个函数，你的调用者给你发了一串注入攻击参数（这个算可能发生的）。假如你出处理不了，那么结果可能是攻击者成功骗过你拿到了那想要的返回数据，也可能是你的程序被搞挂（你抛了异常）；当然，你也可能这个攻击你能够识别，那么处理方法是你要告知调用者参数错误，你可以用返回码也可以用异常，这个事情可以取决于很多因素，比如： * 调用者的代码是你自己维护的，你想追求代码的可读性好，愿意用异常 * 你封装的函数其实是一个微服务，别人是通过HTTP来调用你的，那你只能跟调用者定义一套返回码了 * 调用者其实是UI界面的操作者，那么其实 返回码 和 异常 可以都没有，但你却要给一个UI错误提示 所以，基于以上的讨论，个人观点是， 对于你处理不了的，抛异常就好了；如果是你能处理的异常，那么要看这个异常的下游要交给谁： * 交给代码处理的，可以用异常，也可以用错误码，取决于团队文化 * 交给微服务的，只能用错误码。如果是RPC的话，可以用异常，但是调用者要能识别你抛出的异常就要经常更新异常的定义，这个在实践中很低效 * 交给用户处理的，要讲的是用户体验好。用户看不见的log你打了就可以了

对于上面三种错误的种类来说，程序中的错误，可能用异常捕捉会比较合适；用户的错误，用返回码比较合适；而资源类的错误，要分情况，是用异常捕捉还是用返回值，要看这事是不应该出现的，还是经常出现的。 —— 这三种分类和处置方式比较赞同。 但实际在多人协作项目，或大型项目中多方技术人员要在这个层面理解达成一致不是那么容易的事情。如果依赖于解决架构负债，架构升级来优化，驱动力又似乎不足。

>异常捕捉的确是对性能有影响的，那是因为一旦异常被抛出，函数也就跟着 return 了。而程序在执行需要处理函数栈上的上下文，这会导致性能变得很慢，尤其是函数栈比较深的时候 异常抛出和不抛出，函数栈的深度应该差不多吧？函数栈的上下文会有啥不同？

不是java的示例哦，java没有指针一说，看是能看明白意思，示例看着有点感觉自己门外汉，像是自己在学英语，然后讲解的人用另一门类似的语言在解释英语的意思一样，买课程只看了目录，作者简介写了骨灰级程序员，我以为是自己熟悉的java的讲解呢，因为自己是个半路出家的程序员，所以对c还是不太了解，今天只是选了这篇学习，不知道其他的文章是不是也都是C代码做示例讲解的哦，如果都是C的话，学起来就别扭了

我们大不部分都是定义自己的异常处理类，然后各种异常都定义好错误码，返回给调用者，这样很清晰的就知道什么问题了

我是个零基础学员，我表示可以看完一遍，但是啥懂不懂 目前就知道以后遇到类似错误纠正的事，那我就再来这里重新查看，寻找答案。哈哈，这算是收获吗？

错误码、异常处理都是在不同场景下的结果，同步可直接获得，异步不能