Inconsistent error format

[Wittiest]

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]

@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]

@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.