为啥要在 Webflux 应用程序中构建自己的错误/异常处理？

Posted 2023-03-28

【中文标题】为啥要在 Webflux 应用程序中构建自己的错误/异常处理？

【英文标题】：Why should I build my own error/exception handling into a Webflux application?为什么要在 Webflux 应用程序中构建自己的错误/异常处理？

【发布时间】：2019-09-17 17:46:52

【问题描述】：

当 Webflux 应用程序中存在一些内部异常时，为什么我想要/需要编写代码来处理这些异常？我了解当服务客户端错误地调用服务或发生非错误条件（即查询返回空光标等）时处理问题并返回适当的 ServerResponse 正文。

但是，除了将调试信息生成到日志文件之外，滚动你自己的异常处理组件还有什么好处吗？这种方法在单体应用程序中对我来说“更有意义”，在这种情况下，人们试图避免应用程序“死掉”的情况。

但是，对于服务实现，特别是如果有一些动机不向客户端公开太多内部实现，为什么 Spring 的默认错误/异常处理（和“500 内部服务器错误”响应/消息）不足够了。

【问题讨论】：

一个例子可能是，在测试环境中运行服务器时，您希望返回给客户端的错误消息比在生产环境中更详细。因此，您编写了一个自定义异常处理程序 t，它将在测试期间向客户端提供更详细的信息。如果使用“test”配置文件启动服务，我通常还会添加一个名为“debugMessage”的参数，该参数会返回给客户端。这个 debugMessage 任何人都可以在抛出异常时传递，在这里你可以传递有关请求的详细信息。您不想在 prod 中向客户端公开的内容

是的，我一直在考虑这些思路（即，在生产中对客户端隐藏实现，将信息/警告/错误信息添加到日志等）。还有“如果没有别的，至少我们没有使用其他人的实现”的论点（对于底线问题不太好，但在考虑安全性时“更好”）。

【参考方案1】：

所以，经过一段时间的思考（以及很少，但仍然有帮助和赞赏的反馈），我想它可以归结为：

(a) - 它为“做事”提供本地化上下文，例如记录有关异常/错误条件的信息，或在服务器-客户端交互的上下文中对异常的严重性进行分类。

(b) - 它根据异常/错误情况的性质以及服务器是部署在生产环境还是测试环境中，提供本地化上下文以隐藏/向客户端公开信息。

(c) - 本地化后，维护/修改更容易，因为异常/错误的处理不会分散在整个代码中。

（a）和（c）足以让我相信这是值得的。