引发异常：字符串与自定义类答案

【问题标题】：Raising an an exception: string vs custom class引发异常：字符串与自定义类
【发布时间】：2023-03-23 15:24:01
【问题描述】：

有什么好处吗：

ApiTokenExpired = Class.new(StandardError)
...
raise ApiTokenExpired if response.errorCode == 429

在这个更懒惰的选择上：

raise 'api token expired' if response.errorCode == 429

考虑到这种错误检测在代码中只发生一次？

【问题讨论】：

标签： ruby exception exception-handling

【解决方案1】：

如果您必须在调用堆栈中的某处以特定方式处理错误，则自定义错误（如 ApiTokenExpired）有一个重要优势。

begin
  # ...
rescue ApiTokenExpired => error
  # handle the specific error
rescue => error
  # default error handling 
end

IMO 创建自定义错误的决定并不取决于项目的规模或未来的维护。

由于自定义错误类会导致额外的工作，我默认不使用它。当需要特殊的错误处理时，应该引入一个错误类。

【讨论】：

不确定我是否理解您的最后一句话。你的意思是你会在大多数时候使用自定义错误，因为开销可以忽略不计？
@JeromeDalbert 默认情况下我不使用自定义错误类。当我需要特定的错误处理时，我会使用这种方法。自定义错误类的开销应该是合理的。
@JeromeDalbert 我在答案中调整了我的解释。希望，现在更清楚了。
谢谢，我对这个答案很满意。雅格尼

【解决方案2】：

如果您的应用程序设计为具有错误处理功能或计划在未来（我的意思是，任何成功的系统都希望有一天，对吗？），您可以对字符串做的唯一事情就是读入它日志或在错误消息中显示它，您可以使用类型以解耦的方式编码各种事物。

例如，ApiTokenExpired 可以通过“重试”响应来处理，因为它是一个外部问题，或者通过更新 API 令牌所需的步骤来处理（如果您使用了 Typed Exception，您可以稍后将其插入！ )，也许您希望所有被认为是严重或意外的错误都向系统管理员发送一封电子邮件，并存储有关错误频率的统计信息，键入的异常允许您根据何时执行的操作编写任何您想要的代码你的系统有问题。

【讨论】：

【解决方案3】：

使用第一个，当代码嵌入到更大的软件中时，您可以通过类有选择地挽救该错误。您仍然可以对第二个使用错误消息字符串的模式匹配来执行此操作，但通常，由于重构，您可能会随着时间的推移更改消息格式（与使用第一个表单更改异常类的可能性相反），并且也可能存在具有相似消息字符串的不同异常，这两种异常都可能破坏模式匹配。当您考虑将来的维护时，第一个更好。

【讨论】：