Handling response codes in a DRY way

[iftheshoefritz]

I understand that it's useful to be able to check http response codes once you've received a value from the API. However doing something like this:

response = Pandadoc::Api::Document.download
case response.code
when 429
  # handle rate limiting
when 4xx
  # handle bad client input
when 5xx
  # handle no response

... in my code for every different call seems bad. I'm considering contributing a patch and wondering about direction:

• expose bang methods Document.download!, Document.create! that raise e.g. Pandadoc::Api::TooManyRequestsError for 429 (I won't just change the original methods... assuming that people will not appreciate it if suddenly this library starts raising errors when they expect to be able to safely inspect response codes)
• alternatively, adding info to the object returned by the client: response.success? etc. Admittedly I'm not sure what info I'd add for rate limiting if I did this

This was all sparked by finding out that after 9 months of thinking this library was safely giving us PDFs, we found out that most of the "PDF" files we saved were actually just JSON: {"type"=>"request_error", "detail"=>"Request was throttled. Expected available in 1 second."}

[mikecx]

Hey @iftheshoefritz, some good feedback there and something we hadn't hit yet due to our usage patterns. The return object already has response.success? so you should be good to go if you decide to go down that path.

Looking at our usage of it, we have it contained in a small wrapper class. In our wrapper we raise PandaDocError, response.as_json unless response.success? and then parse the error message out in the PandaDocError class using the type and detail fields. While it works, I can certainly agree with you that it doesn't feel super clean or DRY.

If you'd like to create that PR to add the bang methods, i'm all for it.