<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 02/02/2016 05:29 PM, Lang Hames via
llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:CALLttgo6VZAMFvv=bFF1MwDQuFBwOjKCQNNuO2hfTuRQ9oT8Xw@mail.gmail.com"
type="cite">
<div dir="ltr"><span style="font-size:13px">Hi All,</span>
<div style="font-size:13px"><br>
</div>
<div style="font-size:13px">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.</div>
<div style="font-size:13px"><br>
</div>
</div>
</blockquote>
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.<br>
<br>
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. <br>
<br>
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.)<br>
<br>
Philip<br>
<br>
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. <br>
<br>
<br>
<br>
</body>
</html>