【注】本文翻译自：JavaExceptions-DZoneJavaJavaExceptionJavaException是为处理异常应用程序行为而创建的类。在本文中，我解释了如何使用Java异常类以及如何在考虑Java异常的现有设计的情况下创建异常结构。Java异常概念是Java的重要里程碑之一，每个开发人员都必须了解它。Java异常结构比你想象的更有用Java异常结构非常有用，可以告诉开发人员一组重要的事情（如果开发人员正确使用这个结构）。所以，在这里你可以看到基本结构：捕获所有可能情况的主要父类是Throwable，它有2个子类：Error和Exception。Java错误Java错误表示异常情况。如果出现错误，应用程序可能会关闭。Java异常与错误不同，Java异常提供了从问题中恢复应用程序并尝试保持应用程序运行的机会。异常也分为两类：异常以运行时异常和非运行时异常表示，也称为检查异常。这种分类与错误异常非常相似，但在这种分类中，检查异常在恢复方面更为乐观。已检查异常和未检查异常在Java中，有两种类型的异常。检查异常迫使开发人员创建处理程序异常或重新抛出它们。如果重新抛出已检查的异常，则java函数必须在其签名中声明它。未经检查的异常unlinechecked不需要任何处理。这样的设计意味着uncheckedexception无法处理，注定要抛给顶层父类。ErrorExceptionInvestigation有两种方法可以处理抛出的异常：在当前方法中处理它或者直接重新抛出它。没有比这更好的方法了：您可能有一个父处理程序或以某种方式处理它，比如创建重试逻辑。Good,bad,ugly介绍完之后，我们可以把所有的异常分为3组：Checked、Runtime和Error。主要思想是他们每个人都会陷入不同的境地。最乐观的是Checked异常。运行时将是恢复机会很低的情况之一。而且，最悲观的是Error。检查，运行时，错误......然后？知道了异常类的类型，我们就可以回答下一个问题：情况有多糟糕，问题的原因是什么。如何解决这个问题呢。我们需要重新启动JVM吗？我们需要重写代码吗？知道了异常类，我们就可以预测可能会出现什么问题。考虑到根本原因，我们可以假设问题的原因是什么以及如何解决它。让我们回顾一下最流行的场景，看看这些异常能告诉我们什么。在接下来的段落中，我们将回顾著名的异常并调查底层代码是什么。在我们的调查中，我们假设应用程序足够稳定并且开发阶段已完成并经过测试。错误异常调查我们从最悲观的案例或者我们的丑小子开始。Error真的有那么丑吗？让我们来看看最常见的Java错误：因此，在大多数情况下，您需要做的就是更改JVM配置或添加缺少的依赖项。仍然存在需要更改代码的情况，但他们不太可能在所有情况下都应用这些更改。检查异常调查对于检查异常，我们期望有机会从问题中恢复；例如，再试一次。在本节中，我们将回顾最著名的检查异常。提供的例外可能是彼此的父母，但是，在这里，我只列出最常见的情况，而不关心它们之间的关系：嗯，有很多例外，但是，正如我所承诺的，我把最常见的例外在这里。那么，这张表说明了什么？如果我们查看最可能的原因，我们会发现其中大多数不仅不需要更改任何代码，甚至不需要重新启动应用程序。所以，很明显，检查异常应该是好的。运行时异常调查最常见也是个人最悲观的异常：运行时。Checked和Error异常错误不会导致任何代码更改。然而，在大多数情况下，运行时异常突出了代码中的真正问题，如果不重写代码就无法修复这些问题。让我们通过查看最流行的运行时异常来找出原因：一个示例可能会给人一种印象，即任何运行时异常都会导致应用程序失败。在大多数情况下，这是真的，因为如果不更改代码就无法恢复应用程序。最终，运行时异常是我们的坏人，它会导致新的代码更改、开发人员压力和业务损失。一些批评在这次审查中，我们做了一个很大的假设：代码已经准备好生产并且经过了良好的测试。然而，在实践中，这很难实现。所以，我们得出的结论并不是100%可靠的，但是代码越稳定，结果就越符合实际。已检查异常和代码污染根据已检查异常，设计开发人员必须使所有可恢复异常都可检查。因此，每次调用带有已检查异常签名的方法都会向TryCatch结构添加3-4行。这种方法使代码难看且可读性差。就个人而言，我更喜欢使用运行时异常。即使在设计库的情况下，您仍然可以在方法签名中保留运行时异常，并在API中添加一些注释。在这种情况下，您的API用户将能够决定如何处理它。
