iX8NEGGn

是的，莫名其妙，怀疑快递那里有自己的数据库，我之前一直用另一个名字，后来改了，现在购物软件和快递包装上显示的都是现在的名字，但是快递员那里显示的是之前的名字。

对洗衣机没损坏，对鞋有损坏，得买那些动力不那么足的洗鞋机。

#7 ++，我也是开着休眠，照样可以唤醒。

是的，你设计的 API （函数、或者 HTTP 接口）抛出的异常，应该面向你的用户（调用方）来设计，而不是根据你内部实现由其他函数决定。内部实现的其他函数抛出的异常，你函数内能处理的就处理掉，能转换的就转换成你调用方关心的，最后不能处理的才往上抛。

我好像看错了，你说 API 文档是提供给开发人员的类文档，我还以为是对接 SDK 之类的网络接口文档。

你想说的是如何给每个方法生成运行时异常说明？这是靠规范来达到的，每一个方法都有义务对它抛出的异常进行文档声明，然后上层调用时要进行捕获、转换或继续往上抛，这一层又有义务对它抛出的异常进行声明。

每一层 catch 到异常，能处理的处理，不能处理一般会对异常进行转换后才往上抛，而不是无脑的直接一直往上抛，最后抛给用户一个非常底层的异常。

因为同一个底层异常，对于不同上层来说含义可能是不一样的，最终给到用户的异常，应只是用户关心的异常，API 文档中总结出来的错误码只是用户关心的错误码。

比如登录接口，你应该只告诉用户账户不存在、密码错误等异常，对于什么数据库连接失败、各种工具类抛出的异常用户不关心，你应该将它们全部转换成一个“服务器异常”，而不是告诉用户细节：数据库连接失败异常、XXX 工具类异常。

你的误区在于认为直接给每一个异常一个错误码，然后一条路抛到黑，那 API 文档中就要总结出各种各样的异常。

云鲸逍遥 001 ，这些扫地机器人要是能刷机或自定义算法好了

买跨界钢琴，或买真钢安装静音系统，扰民问题就解决了。

我真的超喜欢这个，用了几年了：

https://s21.ax1x.com/2024/06/13/pkaf2an.jpg

一档微风，开一整天都不会觉得皮肤不舒服，二档风力够，热的时候也能应付，USB 供电，我两万毫安充电宝可以开很多天。