Repository navigation
CloudinaryException is too vague #338
Description
Activity
👍 I like the idea of segmenting these errors into ones that should be retriable and not. Sometimes a
CloudinaryExceptioncan represent a transient network error or downtime event that should be retried, like these:cloudinary_gem/lib/cloudinary/uploader.rb
Lines 331 to 342 in 25df5fd
For backward compatibility, the specific errors raised can both be subclasses of
CloudinaryException.Reacted by Marco AntonioReacted by Ben OakesHi @benjaminoakes, @nilbus. Thank you for your feedback! I'm going to pass it forward to our engineers to review. We'll update here with any updates.
Reacted by Ben OakesReacted by Ben OakesReacted by Ben Oakes
We've seen messages like
Resource not foundandError in loading, which we'd like to handle as generic HTTP client errors (400-499). Unfortunately, we have to rescue theCloudinaryException, 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::HttpClientErrorto 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; endand then use that error for the cases that represent HTTP 400-499.