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

[Philip Reames via llvm-dev]

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>