Hi Frank, On Mon, 2020-10-26 at 08:15 -0400, Frank Ch. Eigler via Elfutils-devel wrote: > > > Sure - or could use something like -EPROTO "Protocol error". > > > > Do you believe the caller should be able to detect how the connection > > was refused? And if so, is EPROTO the most appropriate error code, or > > should it be something like ENOKEY? > > I don't think it really matters to a debugger why exactly a request > failed. A human user might be able to take different action on an > ordinary 404 (buildid is just not indexed) vs. other things that > indicate system configuration or connectivity problems, but I wouldn't > bother try to pass maximum curl/http fidelity back through mere errno > codes.
OK, then I'll keep it as ECONNREFUSED, which I think covers the error better than ENOENT. > Maybe for purposes of smarter clients, we could extent the > debuginfod_client object with the curl return code, and then have > debuginfod-find print that too. That might be an idea, or add a "user friendly" last error message function (so the user code doesn't need to interpret curl return codes). Thanks, Mark
