应将XML解析异常封装为业务异常InvalidOrderXmlException，继承RuntimeException，提供含消息和cause的构造方法，在catch块中按错误类型转换并保留原始异常，配合@ControllerAdvice统一返回标准化错误响应。
在解析 XML 时遇到格式错误、缺失字段或语义不合法等情况，不应直接抛出 ParseException、SAXException 等底层技术异常，而应封装为明确的业务异常（如 InvalidOrderXmlException），让调用方清晰感知“不是系统故障，而是输入不符合业务规则”。
定义清晰的业务异常类
继承 RuntimeException（非检查异常，避免强制 try-catch 干扰业务流程），并提供构造方法支持携带原始异常和业务上下文：
// 示例：订单 XML 格式异常
public class InvalidOrderXmlException extends RuntimeException {
public InvalidOrderXmlException(String message) {
super(message);
}
public InvalidOrderXmlException(String message, Throwable cause) {
super(message, cause);
}
}
在 XML 解析逻辑中主动捕获并转换异常
使用 DOM、SAX 或 JAXB 解析时，在 catch 块中判断错误类型，按需转为业务异常：
- 对
ParserConfigurationException、SAXParseException等——说明 XML 语法/结构非法，转为InvalidOrderXmlException("XML 格式错误: " + e.getMessage(), e) - 对空节点、缺失必填字段（如
order.getId() == null）——属于语义校验失败，同样抛InvalidOrderXmlException("订单ID不能为空") - 对数字格式错误（如
<amount>abc</amount>）——捕获NumberFormatException后包装为业务异常，而非暴露技术细节
保留原始异常用于排查，但不暴露给上层业务
业务异常构造时传入原始异常作为 cause，既满足日志追踪需要，又保持接口干净：
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
// 日志中可打印完整堆栈，但 Controller 层只处理 InvalidOrderXmlException
try {
Document doc = builder.parse(xmlStream);
return parseOrderFromDocument(doc); // 自定义语义解析
} catch (SAXParseException e) {
throw new InvalidOrderXmlException(
"第 " + e.getLineNumber() + " 行，列 " + e.getColumnNumber() + "：XML 格式错误", e);
} catch (Exception e) {
throw new InvalidOrderXmlException("解析订单XML失败", e);
}
统一异常处理（可选但推荐）
在 Spring MVC 中，用 @ControllerAdvice 拦截业务异常，返回标准化错误响应：
@ExceptionHandler(InvalidOrderXmlException.class)
public ResponseEntity
return ResponseEntity.badRequest().body(
new ErrorResponse("INVALID_XML", e.getMessage()));
}
}
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
