Improved error messages

[mstahl]

When an API returns an error object with both title and detail keys defined, the error message returned from json_api_client should include both, since sometimes the detail includes crucial debugging information. One example is a 400 response for an invalid param:

Before: Param not allowed
After: Param not allowed - The parameter "foo" is not recognized

Users of the API client are then better equipped to recognize and fix bugs.

[mstahl]

The failing bid timed out and I can't re-start it:

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received
The build has been terminated

Can someone please re-trigger it so that I can see if it's a real error or just a stalled build?

[chingor13]

This change could affect current users of this functionality by changing the default error message. If this is changed to be a configurable method, you can change your base class' error message formatter to the behavior you want.

Please also add a test for this so we don't regress in the future.

[chingor13]

Does this belong as an instance method? If it's extracted here, perhaps it belongs as a class method for this resource. It can still be overridden by a child class if you so choose.

[mstahl]

Thanks @chingor13 for your comments. I'll make these changes probably tomorrow night or Friday and resubmit.

[senid231]

hi @mstahl
I think now you can add functionality that you need by overriding JsonApiClient::ErrorCollector::Error#error_msg in your application

take a look at lib/json_api_client/error_collector.rb:51
and PR #277

Does it allows you to handle API responses correctly?