[llvm-dev] [RFC] Error handling in LLVM libraries.

[Lang Hames via llvm-dev]

Hi Sean,

> Yeah, the ability to breakpoint in the diag handler is a huge win!

I think both schemes support that equally well. In my scheme, if you have
an error MyError, you can just write:

(lldb) b MyError

to set a breakpoint on the constructor.

- Lang.

On Tue, Feb 9, 2016 at 2:27 PM, Sean Silva <chisophugis at gmail.com> wrote:

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