Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent error format #999

Open
Wittiest opened this issue Sep 4, 2021 · 2 comments
Open

Inconsistent error format #999

Wittiest opened this issue Sep 4, 2021 · 2 comments
Assignees
Labels

Comments

@Wittiest
Copy link

Wittiest commented Sep 4, 2021

As a user of the stripe-ruby gem, I expect to be able to handle errors in a generic way.

The current implementation of the error object creates a world where we cannot be sure of when to use code that accesses stripe.error or stripe.message.

Consider the case of exceptions which always have an error object:

require 'stripe'

Stripe.api_key = 'VALID_API_KEY'

def cause_invalid_request_error
  Stripe::Product.create()
rescue Stripe::InvalidRequestError => e
  puts e.error.type
  puts e.message
end

cause_invalid_request_error

# => invalid_request_error
# => Missing required param: name.

The case of exceptions without an error object:

require 'stripe'

def cause_auth_error
  Stripe::Product.create()
rescue Stripe::AuthenticationError => e
  puts e.error.type
  puts e.message
end

cause_auth_error

# => test_errors.rb:6:in `rescue in cause_auth_error': undefined method `type' for nil:NilClass (NoMethodError)

It would be nice if the SDK handled wrapping errors and exposing methods in a way that allows for us to generically handle and output all of the possible details.

In the current case, there is a subset of fields available on some errors, so it feels like e.message and a few others are the only safe access we have

@remi-stripe
Copy link
Contributor

@Wittiest thanks a lot for the detailed report/repro. We'll look into it, I agree we should support the direct access through e.error for all error types

@remi-stripe
Copy link
Contributor

@richardm-stripe it looks like we set the e.error shortcut when de-serializing the raw JSON from the API here. The problem is that in some parts of the library, we might raise an error directly with a raw message which doesn't go through the same steps. The example above is raised here for example.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants