CloudinaryException is too vague

未关闭
#338 3 条评论 1 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
停滞
技术栈
ruby
领域
api, backend

调研方向

定位 CloudinaryException 以及当前生成诸如 "Resource not found" 和 "Error in loading." 等消息的 HTTP 响应处理逻辑。跟踪 400–499 响应是如何分类的,然后定义异常层次结构,并验证相关的客户端错误是否可以分别捕获。该 issue 没有提及具体文件或测试,因此应首先确定现有的异常和 HTTP 客户端测试覆盖范围。

由索引模型根据 Issue 内容生成。

描述

enhancement

We've seen messages like Resource not found and Error in loading, which we'd like to handle as generic HTTP client errors (400-499). Unfortunately, we have to rescue the CloudinaryException, check its error message, and then determine what should be done.

I would propose having more than one exception class to make it possible for us to rescue something like Cloudinary::HttpClientError to ignore errors like HTTP 403 (Forbidden), 404 (Not Found), 408 (Request Timeout), etc.

One way to do this would be to add class Cloudinary::HttpClientError < CloudinaryException; end and then use that error for the cases that represent HTTP 400-499.

主要语言
Ruby
星标
420
派生
282
PR 合并指标
30 天内没有已合并 PR

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

cloudinary/cloudinary_gem 的其他 Issue

查看 cloudinary/cloudinary_gem 的全部 Issue

相似的 Issue

更多 Ruby Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。