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

[Rafael Espíndola via llvm-dev]

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.

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.
* Defining TypedError as a wrapper over std::error_code with a
destructor that verifies the error was handled?

Thanks,
Rafael