我继承的项目之一充满了大量捕获一般异常的try/catch block 。我一直在缓慢但坚定地重构这一点，但有太多问题，以至于我一直在考虑在 session 上将其作为一个问题提出。这让我开始思考......是否真的存在在生产环境中捕获一般异常是合理的情况？我想不出我需要捕获一般异常的情况，但我也是一个刚刚毕业的人，我确信还有很多我不知道的事情。我做了一些研究，我可以找到很多为什么不捕获一般异常的原因，但没有具体说明这种做法何时合理。显然，如果您调用的方法已经抛出异常，则必须捕获它。但是是否有某种原因导致某些方法可能抛出Exception并且不应该重构它来抛出特定的异常？
最佳答案
仅当您需要抛出异常时才抛出异常。如果您抛出过于笼统的异常，那么您实际上只是大喊“有问题”，而没有提供有关该问题是什么的具体信息。
仅在抛出 Exception 时捕获 Exception 仅。如果您捕获的异常过于笼统，您就会失去以正确方式处理特定异常的机会。
抛出Exception相当于返回Object，而不是返回对调用者有用的更具体的类型；捕获Exception相当于将返回值分配给Object变量，而不是可以用来做有用事情的更具体的类型。基本上:您正在丢弃可用的类型信息。
有时您必须抛出异常，因为您正在编写一个通用框架。例如，Callable.call抛出Exception，因为你不知道那里会执行什么代码，所以允许它抛出Exception意味着您不限制该类的用户。因此，如果您调用 Callable，则需要捕获 Exception；但您需要小心行事。
绝大多数人没有(或不应该)编写框架，因此您不应该抛出或捕获异常。
Effective Java，第 61 条“抛出适合抽象的异常”对此有很好的建议(这是第二版中的数字；不知道第三版)。基本上:你几乎肯定不想抛出Exception，但你可能想抛出IOException而不是FileNotFoundException，如果事实上你正在读取与您的 API 无关的文件。
关于java - 什么时候抛出/捕获一般异常是可以接受的，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49491390/