Open bgentry opened 11 years ago
Also thinking that a --debug
flag or similar env that shows request / response body might be helpful.
Field message
is designed for showing to the user, so we should start by printing it as-is on stderr. We can also recognize the value of field id
if we think we can do better than the provided message. And as a last resort (if we don't know the id and there's no provided message) we can do what we currently do as well as printing out the raw response body.
Per the v3 API docs, failing requests are returned error messages like the following:
However, when a command fails, the output from
hk
looks like this:I'm thinking that there should be a way to expose those error fields in the output. Even if it's not the default, it would make it easier to develop the client if those fields were available by default.
Any thoughts on how to do that? A
key=val
format feels unnatural here:as does a
:
-separated list:Ugh, line breaks in API error messages :rage: