illformedlocaleexception不是非受检异常，而是继承自java.lang.exception的受检异常，编译器强制要求捕获或声明，常见于非法语言标签解析场景。
IllformedLocaleException 是 Java 中一个受检异常（checked exception），不是非受检异常（unchecked exception）。这一点非常重要——它直接影响你是否必须显式处理该异常。
它到底是不是“非受检异常”？
不是。IllformedLocaleException 继承自 RuntimeException 的说法是错误的。它实际继承自 java.lang.Exception，属于典型的受检异常。这意味着：
- 编译器会强制要求你捕获它或在方法签名中声明抛出
- 常见触发场景是调用
Locale.forLanguageTag()或new Locale.Builder().setLanguageTag(...).build()时传入格式非法的语言标签（如 "zh-CN-xxx"、"en--US"、空字符串等） - 它和
IllegalArgumentException不同——后者才是非受检异常，而IllformedLocaleException明确要求处理
为什么容易误认为它是非受检异常？
主要原因有三个：
- 异常名称带 “Exception” 却出现在看似“安全”的 API（如
Locale.forLanguageTag()）中，开发者习惯性忽略 try-catch - 部分旧版文档或博客表述不准确，混淆了“与 Locale 相关”和“运行时异常”的概念
- 实际开发中常配合
Optional或预校验规避，导致很少见到显式 catch，误以为无需处理
正确使用方式：捕获 or 声明？
推荐优先捕获并转换为更明确的业务异常或日志提示，而非向上抛出：
- 不要简单 throws —— 上层通常无法修复语言标签格式问题
- 建议用 try-catch 包裹，并提供可读错误信息，例如：
throw new IllegalArgumentException("Invalid language tag: " + tag, e); - 若输入来自用户或配置文件，应在解析前做基础校验（如正则匹配
[a-zA-Z]{2,3}(-[a-zA-Z0-9]{1,8})*），减少异常发生概率
替代方案：避免抛出该异常
Java 9+ 提供了更安全的替代方法：
- 使用
Locale.lookup(…)或Locale.getAvailableLocales()等不依赖任意字符串构造的方式 - 对不确定的输入，先用
Locale.forLanguageTag(tag)尝试，捕获后返回默认 locale 或 null，而不是让异常穿透业务逻辑 - 封装工具方法，统一处理非法标签，例如：
public static Optional<locale> parseLocale(String tag) { … }</locale>
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
