Javatry-catch干货分享：手把手教你优雅处理异常（附案例）

积累知识，胜过积蓄金银！毕竟在文章开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《Java try-catch实战教学：异常处理的最佳实践与案例分析》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

Java中的try-catch用于捕获和处理异常，保证程序在遇到错误时能优雅运行。1.try块包含可能抛出异常的代码；2.catch块定义如何处理特定类型异常，如捕获ArithmeticException并输出提示；3.finally块为可选，用于执行必须完成的操作如释放资源，无论是否发生异常均会执行；4.最佳实践包括精确捕获异常类型而非宽泛捕获、不忽略异常而至少记录日志、使用try-with-resources自动关闭资源；5.当方法无法处理异常或需调用方处理时应抛出异常；6.自定义异常类可通过继承Exception实现，提供更具描述性的错误信息；7.受检异常需显式捕获或声明，适合调用方可合理处理的情况，非受检异常通常表示编程错误无需显式处理。

java中的try-catch主要用于捕获和处理代码中可能出现的异常，保证程序即使在遇到错误时也能优雅地运行，而不是直接崩溃。它提供了一种机制，让你可以在异常发生时执行特定的代码块，比如记录日志、清理资源或者给用户友好的提示。

解决方案

try-catch块是Java异常处理的核心。try块包含可能抛出异常的代码，而catch块则定义了如何处理特定类型的异常。

try {
    // 可能抛出异常的代码
    int result = 10 / 0; // 这会抛出一个ArithmeticException
} catch (ArithmeticException e) {
    // 处理ArithmeticException异常
    System.err.println("除数不能为零！");
    e.printStackTrace(); // 打印异常堆栈信息，方便调试
} finally {
    // 无论是否发生异常，都会执行的代码块（可选）
    System.out.println("程序继续执行...");
}

finally块是可选的，它包含无论try块中是否发生异常都会执行的代码。这通常用于释放资源，比如关闭文件流或数据库连接。

最佳实践在于合理使用，避免滥用。过度使用try-catch可能会隐藏潜在的问题，而忽略异常则可能导致程序崩溃或数据损坏。

try-catch-finally的执行顺序：

• 如果try块中的代码没有抛出异常，那么catch块会被跳过，直接执行finally块。
• 如果try块中的代码抛出了异常，并且有一个匹配的catch块，那么相应的catch块会被执行，然后执行finally块。
• 如果try块中的代码抛出了异常，但是没有匹配的catch块，那么finally块会被执行，然后异常会被重新抛出。

最佳实践1：精确捕获异常，避免catch (Exception e)

捕获过于宽泛的异常类型（比如Exception或Throwable）可能会掩盖更具体的问题。你应该尽可能精确地捕获你期望处理的异常类型。

例如，如果你知道一段代码可能会抛出IOException和SQLException，那么你应该分别捕获这两种异常，而不是简单地catch (Exception e)。

try {
    // 可能抛出IOException或SQLException的代码
    // ...
} catch (IOException e) {
    // 处理IOException
    System.err.println("文件读写错误：" + e.getMessage());
} catch (SQLException e) {
    // 处理SQLException
    System.err.println("数据库操作错误：" + e.getMessage());
}

这样做的好处是：

• 更清晰的错误处理逻辑： 你可以针对不同类型的异常采取不同的处理措施。
• 避免掩盖未知异常： 如果代码抛出了一个你没有预料到的异常，它不会被catch (Exception e)捕获，从而更容易被发现和修复。
• 更好的代码可读性： 代码的意图更加明确。

最佳实践2：不要忽略异常，至少要记录日志

捕获到异常后，什么都不做是最糟糕的做法。这会隐藏潜在的问题，使程序在出现错误时表现得不正常。

至少，你应该记录异常信息，包括异常类型、错误消息和堆栈跟踪。这可以帮助你诊断和修复问题。

try {
    // 可能抛出异常的代码
    // ...
} catch (Exception e) {
    // 记录异常信息
    System.err.println("发生异常：" + e.getMessage());
    e.printStackTrace(); // 打印堆栈跟踪
    // 或者使用日志框架（比如Log4j或SLF4J）
    // logger.error("发生异常：", e);
}

更好的做法是，根据异常的性质采取适当的处理措施。例如，如果一个文件不存在，你可以尝试创建一个新的文件；如果数据库连接失败，你可以尝试重新连接。

最佳实践3：使用try-with-resources自动关闭资源

在处理资源（比如文件流、数据库连接）时，务必确保在使用完毕后关闭它们，以避免资源泄漏。

在Java 7及更高版本中，可以使用try-with-resources语句来自动关闭资源。try-with-resources语句要求资源类实现AutoCloseable接口。

try (BufferedReader reader = new BufferedReader(new FileReader("file.txt"))) {
    // 使用reader读取文件内容
    String line;
    while ((line = reader.readLine()) != null) {
        System.out.println(line);
    }
} catch (IOException e) {
    // 处理IOException
    System.err.println("文件读取错误：" + e.getMessage());
}
// reader会自动关闭，无需手动调用close()方法

try-with-resources语句的优点是：

• 简洁： 无需手动调用close()方法。
• 安全： 即使try块中发生异常，资源也会被自动关闭。
• 可读性： 代码更加清晰易懂。

如果资源类没有实现AutoCloseable接口，你仍然需要在finally块中手动关闭资源。但请务必确保finally块中的代码不会抛出异常，否则可能会掩盖try块中抛出的原始异常。

什么时候应该抛出异常而不是捕获？

何时抛出异常而不是捕获，这取决于你的代码的职责。如果你的方法无法处理某个异常，或者处理异常的责任应该由调用方承担，那么你应该抛出异常。

例如，假设你正在编写一个解析配置文件的方法。如果配置文件不存在，你可以选择：

• 捕获FileNotFoundException并返回一个默认配置。 这种做法适用于你的方法知道如何处理配置文件不存在的情况。
• 抛出FileNotFoundException或一个自定义的异常（比如ConfigurationNotFoundException）。 这种做法适用于你的方法不知道如何处理配置文件不存在的情况，或者希望将处理异常的责任交给调用方。

public class ConfigurationParser {

    public Configuration parse(String filePath) throws ConfigurationNotFoundException {
        try {
            // 读取配置文件
            // ...
        } catch (FileNotFoundException e) {
            // 抛出自定义异常
            throw new ConfigurationNotFoundException("配置文件未找到：" + filePath, e);
        }
        // ...
    }
}

总的来说，你应该遵循以下原则：

• 只捕获你知道如何处理的异常。
• 如果你的方法无法处理某个异常，或者处理异常的责任应该由调用方承担，那么你应该抛出异常。
• 在抛出异常时，提供足够的信息，以便调用方能够诊断和修复问题。

如何自定义异常类？

自定义异常类可以让你更好地控制异常处理流程，并提供更具描述性的错误信息。

要创建一个自定义异常类，你需要：

1. 创建一个新的类，继承自Exception或其子类（比如RuntimeException）。
2. 提供一个或多个构造方法，用于设置异常消息和其他属性。
3. （可选）添加自定义的属性和方法，用于存储和访问异常的额外信息。

public class ConfigurationNotFoundException extends Exception {

    public ConfigurationNotFoundException(String message) {
        super(message);
    }

    public ConfigurationNotFoundException(String message, Throwable cause) {
        super(message, cause);
    }
}

自定义异常类的优点是：

• 更具描述性的错误信息： 你可以提供更具体的错误消息，帮助调用方理解问题的根源。
• 更好的异常处理逻辑： 你可以根据自定义异常的类型采取不同的处理措施。
• 更清晰的代码结构： 代码的意图更加明确。

什么时候应该使用受检异常（checked exception）和非受检异常（unchecked exception）？

Java中的异常分为两种类型：受检异常（checked exception）和非受检异常（unchecked exception）。

• 受检异常： 必须在代码中显式地捕获或声明抛出。如果一个方法可能会抛出一个受检异常，那么它必须在方法的签名中使用throws关键字声明，或者在方法体中使用try-catch块捕获。
• 非受检异常： 不需要显式地捕获或声明抛出。非受检异常通常是RuntimeException或其子类的实例。

你应该遵循以下原则：

• 使用受检异常来表示调用方可以合理地期望处理的异常。 例如，IOException和SQLException通常是受检异常，因为调用方可以尝试重新连接、重试操作或向用户显示错误消息。
• 使用非受检异常来表示编程错误或无法恢复的错误。 例如，NullPointerException和IllegalArgumentException通常是非受检异常，因为它们通常是由代码中的错误引起的，而不是由外部环境引起的。

总的来说，选择使用受检异常还是非受检异常取决于你的代码的职责和调用方的期望。如果你不确定应该使用哪种类型的异常，那么最好使用受检异常，因为它会强制调用方处理异常，从而提高代码的健壮性。

今天关于《Javatry-catch干货分享：手把手教你优雅处理异常（附案例）》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！