Java异常提示需区分类型映射友好文案，未知异常用trace ID兜底并记录日志，禁止直接展示原始消息；服务端决定提示内容，客户端负责渲染，二者解耦。
Java 中捕获异常本身不难，难的是把 Exception 转成用户能看懂、不暴露内部细节、又不丢失关键线索的提示——这不是靠 try-catch 套一层 System.out.println 就能解决的。
用 getMessage() 直接提示用户？危险！
很多初学者会这样写：
try {
int result = 10 / Integer.parseInt(input);
} catch (NumberFormatException e) {
JOptionPane.showMessageDialog(null, "错误：" + e.getMessage());
}
问题在于：e.getMessage() 可能是 "For input string: \"abc\""，也可能是空字符串，甚至包含堆栈路径或敏感字段名。用户看不懂，开发也难定位。
- 永远不要把原始异常消息直接展示给终端用户
-
NullPointerException的getMessage()通常为null，直接拼接会导致显示"错误：null" - 某些框架（如 Spring）抛出的异常消息含内部 bean 名称或 SQL 片段，属于信息泄露风险
区分异常类型，走预设友好文案
对已知可预期的异常，应建立映射关系，用业务语言替代技术描述：
-
NumberFormatException→ “请输入有效的数字” -
IllegalArgumentException（校验失败）→ “用户名长度不能少于3位” -
IOException（读取配置失败）→ “系统配置加载异常，请稍后重试” -
SQLException（唯一约束冲突）→ “该邮箱已被注册”
关键不是“捕获所有异常”，而是只捕获你**明确知道怎么解释**的那几个。其他未覆盖的异常统一走兜底提示（见下一条）。
兜底异常处理必须带 trace ID 和日志记录
无法穷举所有异常类型，但必须确保未知异常不裸奔到界面上：
try {
doBusiness();
} catch (NumberFormatException | IllegalArgumentException e) {
showUserMessage(getFriendlyMessage(e));
} catch (Exception e) {
String traceId = UUID.randomUUID().toString().substring(0, 8);
logger.error("Uncaught error [{}], user={}", traceId, currentUser, e);
showUserMessage("操作失败，请联系管理员（错误码：" + traceId + "）");
}
这样既避免用户看到技术术语，又让后端能通过 traceId 快速查日志定位上下文。注意：logger.error 第三个参数传入 e，才能打完整堆栈。
前端弹窗提示别用 JOptionPane 做生产逻辑
JOptionPane 是 Swing 的调试玩具，真实项目中：
- 桌面应用应走 MVVM 框架的状态绑定（如
JavaFX 的
Alert+ ViewModel 层控制） - Web 后端绝不调用任何 GUI 类——
JOptionPane在无界面服务器上会抛HeadlessException - 真正要“提示用户”，是返回结构化 JSON（如
{"success":false,"message":"用户名长度不能少于3位"}），由前端渲染
所谓“Java 中提示用户”，本质是「服务端决定提示什么」+「客户端决定怎么展示」，二者必须解耦。
最常被忽略的一点：友好提示不是翻译异常消息，而是基于异常类型+业务上下文+用户角色，动态生成语义清晰、行动明确的句子。比如同样是 FileNotFoundException，管理员看到的是“模板文件 config.xlsx 未找到（路径：/opt/app/templates/）”，普通用户只看到“报表生成失败，请稍后重试”。
