fix:correctly identify channel errors with Channel Exception type

[chenzhenhua016]

将渠道错误与系统错误拆分，渠道错误统一使用 OpenAIException

[szl97]

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

[szl97]

Claude finished @szl97's task —— View job

---

代码审查任务清单

• 分析 ChannelException.java 的修改
• 检查各个适配器和回调类中的异常处理更新
• 验证修改的一致性和正确性
• 提供详细的代码审查反馈

代码审查结果

📋 修改概述

本次PR主要将代码中所有使用 ChannelException.fromResponse() 的地方替换为使用具体的 ChannelException.OpenAIException 类型，目标是更准确地识别渠道异常类型。

✅ 积极变化

1. 类型明确化：

   • 从使用通用的 fromResponse() 工厂方法改为直接使用 OpenAIException 具体类型
   • 为 OpenAIException 添加了新的简化构造函数：OpenAIException(Integer httpCode, String message)
   • 移除了未使用的 ExecutionException 导入，清理了代码

2. 一致性改进：

   • 在 16 个文件中统一应用了这一变化
   • 覆盖了所有主要的协议适配器（AWS、Anthropic、OpenAI等）
   • 包括各种回调处理类（ASR、TTS、消息等）

⚠️ 需要关注的问题

1. 语义准确性：

   // 之前：通用异常创建
   ChannelException.fromResponse(httpCode, message)
   
   // 现在：强制使用OpenAI异常类型  
   new ChannelException.OpenAIException(httpCode, message)

   问题：不是所有的渠道错误都来自OpenAI，比如：

   • AwsAdaptor.java:48,123 - AWS Bedrock 异常被标记为 OpenAIException
   • AnthropicAdaptor.java:32,35,207,210 - Anthropic 异常被标记为 OpenAIException
   • HuoshanStreamAsrCallback.java - 火山引擎 ASR 异常被标记为 OpenAIException

2. 命名不一致性：

   • 虽然在 convertToOpenapiError() 方法中有类型检查，但将所有渠道异常都使用 OpenAIException 类型在语义上不够准确
   • 可能会误导开发者，让人以为所有异常都来自OpenAI

💡 建议改进

1. 考虑引入更通用的异常类型：

   // 建议添加一个通用的渠道异常类
   public static class GenericChannelException extends ChannelException {
       // 实现细节...
   }

2. 或者保留 fromResponse 方法：

   • 可以考虑保留 fromResponse() 方法，但让其内部创建 OpenAIException
   • 这样代码语义更清晰，表明这是通用的渠道响应异常

3. 代码注释：

   • 建议在使用 OpenAIException 处理非OpenAI渠道错误的地方添加注释说明
   • 解释为什么使用这种统一的异常类型

📊 影响评估

正面影响：

• 异常类型更加具体，便于异常处理逻辑的识别
• 代码风格更加一致
• 新增的简化构造函数提高了易用性

潜在风险：

• 语义混乱：非OpenAI的异常被标记为OpenAIException
• 可能影响监控和日志分析的准确性
• 未来如果需要区分不同渠道的异常处理逻辑会比较困难

🎯 总体评价

代码修改技术上是正确的，实现了将异常类型从通用改为具体的目标，但在语义设计上存在不足。建议考虑重命名 OpenAIException 为更通用的名称（如 ChannelResponseException），或者为不同类型的渠道创建对应的异常子类。

---