<div dir="ltr">I think we're essentially in agreement. I wasn't trying to say that error handling will be trivial, just that if Pete and Kevin are prepared to do the hard work (which I know they are, since they both want this feature) we should push forward on it.<div><br></div><div>On a side note - you've mentioned a couple of times the danger of dropping errors, which is one of my concerns with std::error_code. Have we considered actually coding in a check for this? I.e. an error type (or diagnostics class) that will fatal_error in the destructor if errors are not explicitly handled or dismissed?</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 15, 2015 at 6:51 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> No comment on the rest of the patch (I haven't read it), but regarding error<br>
> handling schemes I'm not sure I understand the objection. Most users would<br>
> be unaffected by any change in error handling since errors in objects files<br>
> are uncommon. Some users care a lot, but they're the same people<br>
> volunteering to do the development and maintenance (e.g. Kevin and Pete).<br>
> The changes shouldn't place undue burden on anyone else.<br>
<br>
</span>That is not the case. Error handling has a substantial cost in code<br>
complexity and therefore correctness. Broken .o files are uncommon,<br>
but it is important that we can at least error on them.<br>
<br>
My dislike for half attempts to use non fatal errors grew while<br>
looking at the old lld. A good case would look something like<br>
<br>
* main -> foo -> bar -> ... -> zed<br>
* zed finds an error and returns an error_code<br>
* the code in foo, bar, etc is correct and return out the error_code<br>
* main prints a pretty horrible error message (EC.message()) since it<br>
has no context<br>
<br>
That is bad for anyone seeing the error and horrible for anyone<br>
debugging. You have to step in until you find that it is zed that is<br>
producing the error.<br>
<br>
And that is the *good* case. In reality it is pretty likely that some<br>
function along the way forgot to return EC.<br>
<br>
>From that experience I think some properties we must ensure are<br>
<br>
* Diagnostic handling must be done close to where the error is found.<br>
This is very similar to what clang does. The calling functions can<br>
record context and then when zed calls a diagnostic handler it can say<br>
what was the error and what the program was trying to do.<br>
* We have to try to make sure errors are handled. By far the simplest<br>
way to do that is to have fatal errors. This can be done in library<br>
code by passing an diagnostic handler that exits or more simply in<br>
program code by just calling exit.<br>
<br>
The comparison with clang I think is enlightening. In clang good<br>
diagnostic are extremely important since broken c++ files are common.<br>
Since it is a major features, it is treated like that:<br>
<br>
* It uses a diagnostic handler so that errors can be printed with a<br>
lot of context.<br>
* It has special features to make error testing simple.<br>
* It has *lots* of test for its errors and warnings.<br>
<br>
So I can see two self consistent ways of coding objdump<br>
<br>
* We have to detect errors, but they are uncommon and we just have to<br>
make sure we are not silent about it.<br>
* Error handing of broken .o files is a major feature and we treat it like that.<br>
<br>
There nothing in the middle because there no such thing as simple<br>
non-fatal error handling, so the cost is high. If the const is high,<br>
there must be a big justification for it.<br>
<br>
What I cannot possibly understand is saying it is not a big thing but<br>
complicating the code anyway. If we are going to have non fatal (i.e.:<br>
complicated) error handling, I insist that we must:<br>
<br>
* Produce good error messages with good context (foo is broken in the<br>
FDE of function bar of zed.o in bah.a)<br>
* Check in .o files that illustrate every error.<br>
* Have .o files that illustrate we handling multiple error gracefully.<br>
<br>
I.E.: If it is a major feature, treat it like that.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>