<div dir="ltr">Hi Sean,<div><br></div><div>> <span style="font-size:13px">Yeah, the ability to breakpoint in the diag handler is a huge win!</span></div><div><span style="font-size:13px"><br></span></div><div>I think both schemes support that equally well. In my scheme, if you have an error MyError, you can just write:</div><div><br></div><div>(lldb) b MyError</div><div><br></div><div>to set a breakpoint on the constructor.</div><div><br></div><div>- Lang.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 2:27 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">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><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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></div><div>Yeah, the ability to breakpoint in the diag handler is a huge win!</div><span class=""><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></span><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><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- Sean Silva</div><div> </div></font></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
* 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>
</span><span class=""><div><div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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></span></blockquote></div><br></div></div>
</blockquote></div><br></div>