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

Philip Reames via llvm-dev
Wed, 03 Feb 2016 23:02:04 -0000

On 02/02/2016 05:29 PM, Lang Hames via llvm-dev wrote:
> Hi All,
>
> I've been thinking lately about how to improve LLVM's error model
and
> error reporting. A lack of good error reporting in Orc and MCJIT has
> forced me to spend a lot of time investigating hard-to-debug errors
> that could easily have been identified if we provided richer error
> information to the client, rather than just aborting. Kevin Enderby
> has made similar observations about the state of libObject and the
> difficulty of producing good error messages for damaged object files.
> I expect to encounter more issues like this as I continue work on the
> MachO side of LLD. I see tackling the error modeling problem as a
> first step towards improving error handling in general: if we make it
> easy to model errors, it may pave the way for better error handling in
> many parts of our libraries.
>
Separate from the discussion on how we represent errors, we need to
decide what errors we want to detect, which we try to diagnose, and
which are recoverable.  Each of these is a distinct design decision.

For instance, I'd be really curious to hear more about your use case in
Orc and MCJIT.  We're using MCJIT and I've found the error model
presented to be perfectly adequate for our purposes.   I've sometimes
wished that MCJIT did a slightly better job *diagnosing* failures, but I
have yet to see a case where I'd actually want the compiler to recover
from incorrect input rather than failing with a clean message so that I
can fix the bug in the calling code.

One thing I'm seriously concerned about is setting false expectations.
Unless we are actually going to invest in supporting recovery from (say)
malformed input, we should not present an interface which seems to allow
that possibility.  A hard failure is *much* preferable to a soft error
with the library in a potentially corrupt state.  I have seen several
software projects head down the road of soft errors with partial
recovery and it's *always* a disaster.  (Your proposal around
checked-by-default errors is a good step in this direction, but is not
by itself enough.)

Philip

p.s. I'm purposely not commenting on the representation question because
I haven't read the proposal in enough detail to have a strong opinion.



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160203/270805c2/attachment.html>