Java异常类命名规范详解

Java自定义异常类的命名看似简单，实则关乎代码可读性、团队协作效率与系统长期可维护性——必须以“Exception”结尾、采用大驼峰格式、用精准的动宾结构（如InsufficientStockException）直击问题本质，避免模糊笼统的命名；大型项目还可通过BusinessException等语义前缀实现分层治理，但切忌混淆checked/unchecked语义。遵循这些规范，让每个异常名都成为清晰的“错误说明书”，一眼识别、一读即懂、一查就准。

Java中自定义异常类的命名，核心就一条：必须以 Exception 结尾。这不是可选项，而是行业共识和可读性刚需——一眼就能识别这是异常类型，不混淆、不猜测。

必须以 Exception 结尾

所有自定义异常类名都应以 Exception 作为后缀，这是 Java 标准库（如 IOException、IllegalArgumentException）长期确立的约定。

• ✅ 正确示例：InvalidOrderException、PaymentTimeoutException、ConfigLoadException
• ❌ 错误示例：OrderError、BadPayment、ConfigFailure（语义模糊，且无法体现异常本质）

用准确、具体的动宾结构描述问题场景

名称不是越短越好，而是要让人看到名字就大致明白“什么情况下抛出”“问题出在哪”。优先使用动词+名词或形容词+名词组合，避免宽泛词如 GeneralException、UserException。

• 推荐：InsufficientStockException（库存不足）、ExpiredTokenException（令牌过期）、UnsupportedCurrencyException（币种不支持）
• 慎用：UserException（太笼统）、SystemException（与 JDK 的 java.lang.SystemException 易混淆）

严格遵守 PascalCase（大驼峰）命名法

类名每个单词首字母大写，不加下划线，不全小写，不混用大小写风格。

• ✅ 正确：DataValidationException、ExternalServiceUnavailableException
• ❌ 错误：data_validation_exception（下划线，像常量）、datavalidationexception（全小写）、Data_Validation_Exception（含下划线）

可选但实用：通过前缀区分异常性质

大型项目中，为便于归类和治理，可在 Exception 前添加语义前缀，但非强制：

• BusinessException：业务规则校验失败（如余额不足、重复下单）
• SystemException：底层资源异常（如数据库连接断开、Redis超时）
• ApiException：面向外部 API 的统一错误包装（常用于网关或 REST 接口层）

注意：不建议强行加 Checked 或 Runtime 前缀，因为是否检查由继承关系决定（extends Exception 是 checked；extends RuntimeException 是 unchecked），而非名字。

今天关于《Java异常类命名规范详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！