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

[Sean Silva via llvm-dev]

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/05fec95d/attachment.html>