区分SystemException和BusinessException的核心在于异常原因和可控性:前者因基础设施故障导致,后者因业务规则违反引发;其他异常多属开发疏漏。

区分 SystemException 和 BusinessException 的核心在于异常发生的原因和可控性,而不是抛出位置或代码层级。分类的关键是看这个异常反映的是“系统底层出了问题”,还是“业务规则被违反了”。
业务异常(BusinessException):规则没被遵守
这类异常源于业务逻辑本身的约束条件被触发,属于可预期、可校验、可提示用户的场景。
- 用户输入不符合业务要求:比如注册时邮箱格式错误、密码长度不足、年龄填了负数
- 操作违反状态流转规则:如已发货的订单不能再取消、冻结账户不能登录
- 资源不满足业务前提:余额不足扣款、库存为零仍下单、重复提交同一笔支付
- 通常在 Service 层主动 throw,不依赖 try-catch 捕获外部异常
系统异常(SystemException):基础设施不可用
这类异常代表支撑系统运行的某个环节临时失效,属于不可控、不可预测、需运维介入的问题。
Java项目代码review工具。分析Git变更+完整调用链路上下文,推断业务需求,进行多维度评分和分类汇总,生成完整PRD文档。包含细粒度Java代码审查清单(Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 数据库连接失败、SQL 执行超时、主键冲突(非业务逻辑导致)
- 远程服务调用失败(HTTP 500/超时)、MQ 消息发送失败、Redis 连接断开
- 文件系统读写异常(磁盘满、权限不足)、线程池耗尽、配置加载失败
- 一般由框架或中间件抛出,Service 层捕获后包装成 SystemException 再上抛
其他异常(Exception / RuntimeException):未覆盖的盲区
不属于前两类的,基本都归入这一类——通常是开发疏漏或极端边界情况:
立即学习“Java免费学习笔记(深入)”;
- 空指针(NPE)、数组越界、类型转换失败等编程基础错误
- 未对第三方 SDK 返回值做判空、未处理流关闭异常
- 配置项缺失导致初始化失败、JSON 反序列化字段类型不匹配
- 这类异常应被兜底捕获,记录完整堆栈,但不对用户暴露细节
判断小技巧:问自己一句话
如果异常发生后,用户刷新页面重试大概率能成功 → 是 SystemException;
如果异常发生后,用户改个输入或换个操作才能继续 → 是 BusinessException;
如果异常发生后,连开发都不知道为啥会出这个错 → 就是其他异常,需要补日志、加校验、修逻辑。

















