当Webflux应用程序中存在一些内部异常时，为什么我要/需要编写代码来处理这些异常？我了解当服务客户端错误地调用服务或发生非错误条件(即查询返回空游标等(时处理问题并返回适当的ServerResponse正文。
但是，除了将调试信息生成到日志文件中之外，通过滚动自己的异常处理组件有什么好处吗？这种方法对我来说在单体应用程序中"更有意义"，在整体应用程序中，人们试图避免应用程序"死亡"的情况。
但是，对于服务实现，特别是如果有一些动机不向客户端公开太多关于内部实现的信息，为什么 Spring 的默认错误/异常处理(和"500 内部服务器错误"响应/消息(是不够的。
因此，经过一段时间的思考(以及很少但仍然有帮助和赞赏的反馈(，我想它归结为：
(a( - 它提供本地化上下文来"执行操作"，例如记录有关异常/错误条件的信息，或在服务器-客户端交互的上下文中对异常的严重性进行分类。
(b( - 它根据异常/错误条件的性质以及服务器是部署在生产环境中还是测试环境中，提供对客户端隐藏/公开信息的本地化上下文。
(c( - 本地化后，它使维护/修改变得更加容易，因为异常/错误的处理不会分散在整个代码中。
(a(和(c(足以让我相信值得付出努力。