AWTException 与本地化资源异常无关，因其专用于报告 AWT 底层平台交互失败（如 Robot 初始化、剪贴板访问受限），而 MissingResourceException 等属于 Java i18n 机制，由 ResourceBundle 等类抛出，二者无技术耦合。
AWTException 本身**不用于捕获本地化资源异常**，它主要用于报告 AWT（Abstract Window Toolkit）操作失败，比如 Robot 类初始化失败、系统剪贴板不可用、或屏幕捕获受限等底层平台交互问题。它和“本地化资源”（如语言包、Locale 相关的 ResourceBundle、格式化器异常）**没有直接关系**。
为什么 AWTException 和本地化资源异常无关
AWTException 是 AWT 框架在调用操作系统原生 GUI 接口（如 Windows GDI、macOS AppKit、X11）失败时抛出的检查型异常，典型场景包括：
- Robot 初始化失败：系统禁用了屏幕/输入模拟（如 macOS 的辅助功能权限未开启）
- 获取屏幕尺寸或像素数据失败：多屏配置异常、驱动问题或虚拟桌面环境限制
- 剪贴板访问被拒绝：沙箱环境（如某些 Java Web Start 或安全策略限制）
而本地化资源异常（如 MissingResourceException、IllegalFormatException、NullPointerException 在 ResourceBundle.getBundle() 后未判空）属于 Java 国际化（i18n）机制范畴，由 java.util.ResourceBundle、java.text.MessageFormat 等类抛出，与 AWT 的窗口系统交互无技术耦合。
正确处理本地化资源异常的方法
若你在界面中使用了本地化字符串（例如通过 ResourceBundle 加载按钮文本），应单独捕获对应异常，而非依赖 AWTException：
- 使用
try-catch(MissingResourceException e)捕获资源文件缺失 - 对
ResourceBundle.getBundle()的返回值做非空校验，避免后续NullPointerException - 为关键 UI 文本设置默认回退逻辑（如 fallback 到 English 或硬编码默认值）
- 日志记录缺失的 bundle 名称和 Locale，便于定位资源打包或路径问题
如果 AWT 操作触发了本地化相关崩溃？
极少数情况下，某些 AWT 组件（如 JFileChooser、JOptionPane）在渲染时会间接使用本地化资源（如按钮文字、日期格式）。此时异常链中可能出现 MissingResourceException，但它是被包装在 RuntimeException 或 IllegalArgumentException 中，不会变成 AWTException。
建议做法：
- 启用完整异常堆栈（不要只打印
e.getMessage()） - 检查根因是否为
ResourceBundle加载失败，而非 AWT 层面问题 - 确保 classpath 包含对应 locale 的 properties 文件（如
messages_zh_CN.properties），且文件名编码正确（推荐 UTF-8 + native2ascii 预处理）
需要统一兜底？用 UncaughtExceptionHandler 更合适
若希望全局捕获所有未处理的国际化异常（包括影响 AWT 组件显示的），可设置线程级异常处理器：
- 在启动 GUI 前调用
Thread.setDefaultUncaughtExceptionHandler(...) - 在 handler 中识别
MissingResourceException、ClassCastException（常见于错误类型强转资源对象）等，并引导用户切换语言或重启应用 - 避免在 handler 中执行复杂 UI 操作（如弹窗），优先写日志+静默降级
