spring 吞异常
如何避免错误处理应用程序错误的风险？
这将有点吓人。 毕竟，我们在这里正在处理一个致命的杀手。 还有一些讨厌的日志文件。 因此，请紧紧抓住座位！ 我们将提供立即可行的建议，以彻底停止可吞咽的异常。
在这篇文章中，我们的目标是了解如何避免错误处理错误的风险，并且我们将通过理解吞咽异常的负面影响并学习如何解决它们来做到这一点。
我们将调查并找到Java应用程序的无声杀手。 希望我们也能在此期间玩得开心！
现在是时候弄清楚了。
目录
确定我们有问题
研究解决问题的更好方法
一切都始于释放日的忧虑
这种情况可能会让您感到熟悉。 不幸。
新错误会在发布日不断出现，您正在尝试尽快解决它们。 monkeyuser.com最近发布的漫画很好地展示了这一点：
调查已经开始，时机已经过去。 发射日由于某种原因引起焦虑。 我们希望至少今天不是星期五。 星期五下午5点。
日志日志日志，直接怀疑
首先，让我们看看这个典型的日志文件。
假设我们知道我们的应用程序存在问题，因为我们收到了来自用户的很多投诉，或者某些业务指标正在下降，现在我们需要调查发生了什么。 这是一个最近的例子 ，说明可靠性故事成为新闻时的样子。
我们需要查看大量的非结构化数据，试图了解该日志文件对我们隐藏的故事，这可能将是一个繁琐的手动过程。 在这个特定的示例中，我们正在查看其中包含DEBUG和INFO级别语句的文件。 但是在生产中，通常只有WARN及以上版本处于打开状态。 实际上，我们发现在生产中已停用约1/3的日志数据， 您可以在此处阅读有关它的更多信息 。
即使您使用的是日志管理工具，而又不依赖于通过控制台重复操作，它在高级界面中的日志数据也基本相同。
当要知道很大一部分最终用户受到负面影响之前，要知道存在问题就尤其麻烦。 那里杂乱无章，无法理解重要内容。
初步挖掘日志文件后，我们发现有些感觉不对。 还没有线索。 此时似乎更像是猜测。
地块变厚，应用恶心
除了在嘈杂的日志文件中查找生产错误的根本原因之外，还有什么比压力更重的？
没有太多的东西。 好吧，也许有一件事会使整个情况变得更糟。
如果…
我们正在寻找的错误，甚至不在日志中？ ＆＃55357;＆＃56881;
我们试图捕获的沉默杀手逃脱了，在日志中没有留下任何线索。 但是我们仍然需要弄清楚是什么原因造成的。
“无法复制”不是我们可以接受的答案。 并非在这意味着伤害客户并损失收入时。
必须有更好的方法来解决此问题。
回到绘图板
现在我们已经看到了隐藏错误的负面影响，让我们看看它如何与异常联系起来。 为了深入研究，我们想仔细研究一下开发人员在异常捕获块中的操作。 我们看了滑铁卢大学的最新研究论文，该论文使用Github的海量Java数据集来研究这个确切的问题：
“ Java项目中的异常处理模式分析：一项实证研究”，可以在这里访问原始研究，并且我们还发布了分析报告，以复查您可以快速阅读以得出要点的结果 。
这项研究着眼于超过一百万个Java项目，其中包括1600万个catch块，并将它们分为几类。
开发人员在异常捕获块中做什么？
我们看到它基本上分为3组：
- 通过记录日志，打印堆栈跟踪或将信息打印到控制台来记录发生的情况 。
- 抛出一个异常 ，可能是更深的抽象，它使调用堆栈中更进一步的方法之一知道如何处理。
- 而且.....不幸的是.... 没事 一个空块。 吞没异常而没有任何痕迹。 并且看起来它甚至至少与记录日志一样频繁。 至少可以说这真是令人震惊。
繁荣！ 没了 吞下的异常是导致错误不被注意的主要因素。 我们找到了杀手.。
有时开发人员选择忽略它们，而不是通过记录已记录的错误或警告来记录异常来做正确的事情。 发生这种情况的原因可能是因为他们认为不会发生这种情况，或者只是完全忽略了它，试图压制并隐藏它。
快速回顾一下到目前为止，我们已经看到了：
- 在无法预料的情况下对错误进行故障排除非常困难，会对用户造成严重影响。
- 大约20％的错误永远不会写入日志。
- 被吞下的异常捕获在空的catch块中。
未来应该改变什么？
现在，我们了解了吞咽异常的负面影响，让我们来谈谈解决异常所需要采取的措施。
1.代码审查准则
基础知识。 可能需要刷新一些代码审查指南。 确保将来的部署中没有空的catch块，没有任何借口忽略适当的异常处理。
2.日志重构
说这句话可能比做起来更困难，更容易，因为这意味着要深入研究遗留代码。 更新现有代码以包含有意义的日志记录语句，并尝试找出那些空的catch块可能意味着什么。
实施这两种解决方案并发现所有空白的捕获块的一种方法是确保在IDE中打开了代码样式检查。 这是IntelliJ中的样子：
设置->检查->错误处理->空的“捕获”块
3.持续可靠性
我们使用的另一种方法是实施持续可靠性方法并自动进行根本原因分析。 吞噬的异常与否，存在太多的错误情况，以致无法预测所有错误情况，也无法知道需要记录哪些数据才能在将来对其进行故障排除。
我们需要比以往任何时候都更加敏捷，这并不一定意味着易于出错的代码在生产中应该变得松散。 借助自动根本原因（ARC）分析， OverOps可以捕获所有已知和未知错误（100％的异常），无论它们是被捕获，未被捕获，是否被记录，并显示导致它们的完整源代码和变量状态。 它
要查看它在生产和预生产环境中的工作方式，请查看我们的下一个实时演示 ，或者亲自尝试一下，安装和分析您的第一个例外仅需几分钟，请免费试用： 。
OverOps自动根本原因（ARC）分析视图
最后的想法
现在是2018年。让吞咽的例外成为过去。 没有更多的空catch块，也没有更多未知错误。 我们描述的场景听起来很熟悉吗？ 您是否有吞咽异常的其他经历？ 让我们在下面的评论部分中知道！
翻译自: https://www.javacodegeeks.com/2018/02/swallowed-exceptions-silent-killer-java-applications.html
spring 吞异常
878
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
