refactor: restructure exception hierarchy for better clarity

[chenzhenhua016]

重构异常体系，优化异常命名和分类

1. 异常基类重命名：ChannelException → BellaException，OpenAIException → ChannelException
2. 统一渠道错误处理，所有供应商错误使用 ChannelException
3. 规范 getReasonPhrase 使用，统一默认错误类型为 "Channel Exception"

[szl97]

@claude 检查提交的代码，使用中文回复

[szl97]

Claude finished @szl97's task —— View job

---

代码审查任务

审查清单

• 分析异常层次结构重构
• 检查异常类重命名的一致性
• 验证渠道错误处理统一化
• 审查 getReasonPhrase 使用规范
• 提供完整的中文审查反馈

代码审查结果

基于对异常层次结构重构的深入分析，整体重构方向正确且实现较为完善，但存在几个需要关注的问题：

✅ 优点

1. 异常层次结构清晰化

   • ChannelException → BellaException：将原来的渠道异常基类提升为通用异常基类，命名更符合项目整体架构
   • OpenAIException → ChannelException：将原来的OpenAI专用异常重命名为通用渠道异常，体现了供应商无关的设计理念

2. 统一的错误处理模式

   • 所有协议适配器（AWS、Anthropic、火山等）现在都统一使用 BellaException.ChannelException
   • 默认错误类型统一为 "Channel Exception"，提供了一致的错误体验

3. 完善的内部异常子类

   • RateLimitException、AuthorizationException、SafetyCheckException 等专用异常保持不变
   • ChannelException 作为内部静态类，便于管理和使用

⚠️ 需要关注的问题

1. 构造函数设计的逻辑问题 (BellaException.java:150-172)

   public ChannelException(Integer httpCode, String type, String message, OpenapiResponse.OpenapiError error) {
       super(message);
       this.httpCode = httpCode >= 500 ? HttpStatus.SERVICE_UNAVAILABLE.value() : httpCode; // 这里逻辑有问题
       if(httpCode > 500) { // 应该是 >= 500
           message = "供应商返回：code: " + httpCode + " message: " + message;
       }

   问题: 第160行使用 >= 500，第161行使用 > 500，逻辑不一致。建议统一为 >= 500。

2. getReasonPhrase 使用不够统一

   • 在 BellaException 的内部异常类中正确使用了 HttpStatus.getReasonPhrase()
   • 但在其他地方如 AwsCompletionConverter 等仍有直接使用，未完全标准化

3. 异常转换逻辑的完整性 (BellaException.java:87-95)

   public OpenapiResponse.OpenapiError convertToOpenapiError() {
       if(this instanceof ChannelException) {
           return ((ChannelException) this).getResponse();
       } else if(this instanceof BellaException.SafetyCheckException) {
           return new OpenapiResponse.OpenapiError(this.getType(), this.getMessage(), this.getHttpCode(),
                   ((SafetyCheckException) this).getSensitive());
       } else {
           return new OpenapiResponse.OpenapiError(this.getType(), this.getMessage(), this.getHttpCode());
       }
   }

   建议: 考虑添加对其他内部异常类型的专门处理逻辑。

📝 建议改进

1. 修复构造函数逻辑不一致问题
2. 完善单元测试覆盖：重构后的异常层次结构应该有对应的测试用例
3. 文档更新：建议更新相关的API文档和开发指南，说明新的异常处理模式
4. 考虑向后兼容性：虽然是内部重构，但如果有外部调用者，需要考虑迁移指南

总体评价

这次重构很好地简化了异常层次结构，提高了代码的可维护性和一致性。重构涉及43个文件，改动范围广泛但保持了功能的完整性。建议修复上述提到的构造函数逻辑问题后即可合并。

---