应抛出带业务语义的 operationnotsupportedexception 异常，明确标注不支持原因及替代方案，避免空实现或默认值，并通过接口拆分和默认方法将不支持行为显式契约化。

接口实现类中遇到“未支持的方法”，最常见就是抛 UnsupportedOperationException。这不是偷懒，而是 Java 的标准做法——但关键在于“怎么抛才优雅”。核心是：**明确意图、不掩盖上下文、便于调用方识别和处理**。

明确标注哪些方法不支持

在实现类里，对确实不该被调用的方法（比如只读集合的 add()、模板方法中子类无需重写的钩子），直接抛异常，并在注释中写清原因：

• 说明该操作为何无意义（如“本实现为只读视图，不支持修改”）
• 提示替代方案（如“请使用 XXXService 更新数据”）
• 避免只写 // TODO 或空实现

统一使用自定义业务异常（推荐）

直接抛 UnsupportedOperationException 虽标准，但语义偏底层，不利于上层区分业务场景。更优雅的方式是封装成业务异常：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 定义 OperationNotSupportedException extends BusinessException
• 携带错误码（如 ERR_OPERATION_NOT_SUPPORTED）、模块标识、建议操作
• 这样全局异常处理器能统一返回友好提示，日志也能按类型聚合统计

避免在关键路径上静默失败

不要因为“反正没人会调”就留空方法体或返回 null —— 这会让问题延迟暴露：

• 空 return 可能导致后续 NPE，堆栈指向错误位置
• 返回默认值（如 0 或空集合）可能掩盖逻辑缺陷
• 抛异常反而是最诚实的反馈：这里有问题，需要关注

配合接口设计提前规避

真正优雅的处理，其实在接口定义阶段就埋下伏笔：

• 把可选行为拆到独立接口（如 ReadableList 和 WritableList）
• 用默认方法提供安全兜底（如 default void update(...) { throw new OperationNotSupportedException(...); }）
• 让不支持成为显式契约，而非运行时意外

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南