1. Java异常处理的核心原理
1.1 异常模型与调用栈
异常对象是 Throwable 的子类，分为检查型异常和运行时异常，携带类型、消息和栈跟踪，用于描述发生的问题所在。
当方法抛出异常时，JVM 会沿着调用栈向上回溯，在找到能够处理该异常的 catch 块之前，会持续传播。如果没有合适的捕获点，异常最终会导致线程终止并输出栈跟踪信息。
栈跟踪的作用是定位问题根源的路径，它揭示了异常从哪里产生、经过哪些方法，以及在何处被抛出。正确解读栈跟踪是排错的第一步。下面的代码示例展示了异常对象的基本属性和栈信息如何帮助定位问题。
public void parse(String json) throws JSONException {JSONObject obj = new JSONObject(json); // 可能抛出 JSONException// 处理逻辑
}1.2 捕获和传播的机制
try 块用于包裹可能抛出异常的代码，catch 块用于捕获特定类型的异常并进行处理。捕获顺序要从具体到通用，先捕获子类再捕获父类，避免“早捕获”导致错误类型被隐藏。
finally 块无论是否抛出异常都会执行，用于资源清理和环境还原，但需要注意在 finally 中重新抛出的异常会覆盖原有异常的栈信息，影响排错。
正确的模式是在 finally 中仅做必要的清理工作，若有多个异常要处理，最好在 catch 里记录或包装，并在外层抛出最终异常，以保留原始异常上下文。如下示例给出一个常见的结构要点。
public void writeFile(String path, String data) throws IOException {FileWriter writer = null;try {writer = new FileWriter(path);writer.write(data);} catch (IOException e) {// 捕获特定异常并进行处理后再抛出，以保留上下文throw e;} finally {if (writer != null) {try { writer.close(); } catch (IOException ex) { /* 忽略或记录 */ }}}
}2. 常见错误及原因分析
2.1 常见的忽略异常栈信息
在生产环境的日志中，很多异常只记录了简短的错误信息，没有完整的栈跟踪。栈信息是定位问题最直接的线索，忽略它会显著增加排错成本。
捕获异常时，尽量避免仅记录 e.getMessage()，应结合 e 本身输出，或使用日志框架记录完整的栈信息，确保后续追踪到具体调用路径。
下面的示例强调了在日志中保留栈信息的重要性。
try {someMethod();
} catch (Exception e) {logger.error("Error while executing someMethod", e); // 保留栈信息
}2.2 try-catch 的误用与陷阱
过度捕获或捕获过于宽泛的异常，容易隐藏具体异常类型，降低可维护性。仅捕获 Exception 或 Throwable 往往掩盖真实问题，并且可能吞掉应该暴露的错误。
此外，捕获后不做处理直接继续执行，等同于忽略异常，这在设计上是不正确的。应在捕获后进行合理处理、或重新抛出。
权衡示例：广义捕获与具体捕获的对比，展示正确的处理方式。
// 错误的广义捕获
try {riskyMethod();
} catch (Exception e) {// 仅打印，不影响后续执行，容易掩盖问题e.printStackTrace();
}// 改正后的做法：更具体的处理或重新抛出
try {riskyMethod();
} catch (IOException e) {logger.error("IO error", e);throw e; // 重新抛出，保留异常上下文
}2.3 自定义异常与异常层次设计
自定义异常应清晰表达业务语义，避免滥用 unchecked 与 checked 的混合使用。设计应与业务场景匹配，保持层次简洁，避免出现过深的异常层级或模糊的类型含义。
在合适场景下，使用统一的业务异常有助于统一处理策略，但需确保保留原始异常作为 cause，便于事后追踪。构造函数中传递原始异常上下文，能保留完整错误信息。
示例展示了一个简单的自定义异常封装模式。
public class DataAccessException extends RuntimeException {public DataAccessException(String message, Throwable cause) {super(message, cause);}
}// 使用自定义异常包装底层异常
try {dao.fetchData();
} catch (SQLException e) {throw new DataAccessException("Failed to fetch data from DAO", e);
}3. 实战排错技巧与步骤
3.1 重现问题与最小化代码
排错的第一步是明确重现条件，并尽量将问题区域缩小为最小可复现的代码块，以减少外部因素干扰。
在重现阶段，应保留完整的异常栈信息、日志以及相关上下文。最小化代码是排错的关键起点，有助于快速定位问题。
public void process(Data data) {// 最小化复现场景：剥离与业务无关的代码data.validate(); // 可能抛出 IllegalArgumentException// 其他处理
}3.2 使用日志与调试工具定位
日志策略应覆盖异常点、调用栈以及关键变量状态，提高可观测性，并结合调试工具进行断点调试，以便在异常抛出时直接查看变量与路径。
在复杂场景中，使用 分级日志字段（trace/debug/info），有助于在生产环境中低成本定位。
logger.debug("Entering process with dataId={}", data.getId());
try {data.process();
} catch (RuntimeException e) {logger.error("Processing failed at step {}", step, e);throw e;
}3.3 异常处理的正确模式与代码示例
从原理到实战排错，掌握一个清晰的异常处理模式尤为重要：在业务边界抛出有意义的异常、在深层捕获并包装、保持原始异常作为 cause，并尽量避免在 finally 中执行耗时逻辑。
下面展示一个常用的模式：在服务层捕获低层异常，包装为业务异常，调用方按业务语义处理。
// 服务层示例：把底层异常包装为业务异常
public String getUserName(int userId) {try {User user = userRepository.find(userId);return user.getName();} catch (SQLException e) {throw new UserServiceException("Failed to load user with id " + userId, e);}
}