<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 11:12 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3 February 2016 at 02:33, Lang Hames via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Hi Mehdi,<br>
><br>
>> If you subclass a diagnostic right now, isn’t the RTTI information<br>
>> available to the handler, which can then achieve the same dispatching /<br>
>> custom handling per type of diagnostic?<br>
>> (I’m not advocating the diagnostic system, which I found less convenient<br>
>> to use than what you are proposing)<br>
><br>
> I have to confess I haven't looked at the diagnostic classes closely. I'll<br>
> take a look and get back to you on this one. :)<br>
<br>
</span>The main thing I like about the diagnostic system is that it lets us<br>
differentiate two related but independent concepts:<br>
<br>
* Giving the human using the program diagnostics about what went wrong.<br>
* Propagating an error to the caller so that the upper library layer<br>
can handle it or pass it up the stack.<br>
<br>
For example, when given a broken bitcode file we are able to produce<br>
the diagnostic "Unknown attribute kind (52)" which shows exactly what<br>
we are complaining about. We are able to do that because the<br>
diagnostic is produced close to the spot where the error is detected.<br>
<br>
That is way more than what we need to pass to the caller. In fact, the<br>
only cases we need to differentiate are "this is not a bitcode file at<br>
all" and "the file is broken", which we do with the following enum +<br>
std::error_code.<br>
<br>
  enum class BitcodeError { InvalidBitcodeSignature = 1, CorruptedBitcode };<br>
<br>
So we use the context to produce a diagnostic, but the error doesn't<br>
need to store it. Compare that with what we had before r225562.<br>
<br>
Note that with error_code one can define arbitrary error categories.<br>
<br>
Other advantages are:<br>
<br>
* It is easy to use fatal error in simple programs by just using a<br>
diganostic handler that exits.<br>
* Very debugger friendly. It is easy to put a breakpoint at the diag handler.<br></blockquote><div><br></div><div>Yeah, the ability to breakpoint in the diag handler is a huge win!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Given that distinction, what I agree that is really missing is<br>
infrastructure to make sure std::error_code is handled and for<br>
filtering it.<br>
<br>
So, could you achieve your objectives by:<br>
<br>
* Moving the diagnostic handling code to Support so that all of llvm can use it.<br></blockquote><div><br></div><div>Do you mean everything from clang and LLVM? Or just the stuff in LLVM?</div><div>The clang stuff would be a lot of work, but we did something similar for libOption when it started becoming clear that multiple programs would benefit from it (in particular LLD).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Defining TypedError as a wrapper over std::error_code with a<br>
destructor that verifies the error was handled?<br>
<br>
Thanks,<br>
Rafael<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>