clientdetails: handle error interfaces in Details somewhat
#4137
Conversation
mvo5
force-pushed
the
test-clientdetails
branch
3 times, most recently
from
07ceb4c
to
bba6087
Compare
| func TestErrorJSONMarshal(t *testing.T) { | ||
| err := fmt.Errorf("some-error") | ||
|
|
||
| json, err := json.Marshal(clienterrors.WorkerClientError(2, "details", err)) |
There was a problem hiding this comment.
I think I saw a usage of .Details being of type []error but that can get arbitrary complex I guess :-/
maybe we can just cover this as a second use case being marshaled correctly.
This all boils down to the problem that .Details should be "arbitrary"…
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
I pushed a bit of a compromise, needs more tests as it does not test for all the ensureNoErrs cases and also bails on the first nested error (but prints the whole structure so it should be okay).
mvo5
force-pushed
the
test-clientdetails
branch
2 times, most recently
from
6fd78c2
to
c7f6fdf
Compare
| details = fmt.Sprintf("%v", v) | ||
| default: | ||
| if err := ensureNoErrs(reflect.ValueOf(v)); err != nil { | ||
| return nil, fmt.Errorf("found nested error in %+v: %v", e.Details, err) |
There was a problem hiding this comment.
This is probably a bit too terse, maybe found nested error in Details field or something
There was a problem hiding this comment.
For the rare cases (none?) where this will happen, I think it's good :-)
We have no tests for the clienterror, start with a trivial one.
Florian pointed out that `clienterror.Error.Details` could contain arbitrarily deeply nested error values. Add code to detect this. Also deal with the (common?) case that `.Details` contains a list of errors.
mvo5
changed the title
Details somewhat
The clienterror report has no tests right now, that is not ideal so this PR adds some.
While doing that it fixes an issue that @schuellerf discovered, i.e. that when an
errorinterface is passed intoclienterrors.Error.Detailsthe details get lost because the json.Marshaler will not know how to handler anerror interface.
So I think this is fine to merge and will improve the current state. However I think we should rework the
clienterrors.Error so that go types will help us detect issues at compile time. With this PR we will only
detect nested errorrs at runtime and error and it will not deal with nested interface of other types.
We should probably:
clienterrors.Errora real error type, it's kinda unusual that an error does not implement theerrorinterface.Details- AFAICT all the details will be "flattended" (via%v) after the de-serialization anyway, so we might just make details a "string". Of course testing this requires a bit of digging into the source and maybe writting some tests that validate that we indeed just use do the flattening on the other side.