<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 1, 2017 at 11:28 AM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm mostly but not entirely tongue in cheek wondering why we aren't calling llvm::Error llvm::LLVMError, as the lldb error class much preceded it, but that's a minor point.<br></blockquote><div>FWIW I think the naming chosen by LLVM is correct.  It's intended to be a generic utility class, extensible enough to be used by anything that links against LLVM.  As such, calling it LLVMError kind of gives off the false impression that it should only be used by errors that originate from LLVM, when in fact it's much more general purpose.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If it is actually causing confusion (I haven't experienced such yet) I don't mind typing some extra letters.<br></blockquote><div>I think that's in part because llvm::Error isn't very prevalent inside of LLDB (yet).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As we've discussed several times in the past, we often use errors for informational purposes (for instance in the ValueObject system) with no programmatic requirement they be checked.  So the llvm::Error class is not a drop-in replacement for our uses of lldb_private::Error in subset of its uses.  More generally, the environment the debugger lives in is often pretty dirty, bad connections to devices, uncertain debug information, arguments with clang about what types mean, weird user input, etc.  But the job of the debugger is to keep going as well/long as it can in the face of this. For something like a compiler, if some operation goes bad that whole execution is likely rendered moot, and so bagging out early is the right thing to do.  For lldb, if the debug info for a frame is all horked up, users can still resort to memory reading and casts, or some other workaround, provided the debugger stays alive.  This makes me a little leery of adopting an infrastructure whose default action is to abort on mishandling.<br></blockquote><div>Just re-iterating from previous discussions, but it only does that in debug mode.  When you have a release build, it will happily continue on without aborting.  The point of all this is that you catch unhandled errors immediately the first time you run the test suite.</div><div><br></div><div>Even if you have a bad connection, uncertain debug information, etc you still have to propagate that up the callstack some number of levels until someone knows what to do.  All this class does is make sure (when in debug mode) that you're doing that instead of silently ignoring some condition.</div><div><br></div><div>That said, it certainly seems plausible that we could come up with some kind of abstraction for informational status messages.  With that in mind, I'll change my original renaming proposal from LLDBError to Status.  This way we will have llvm::Error and lldb_private::Status.</div><div><br></div><div>In the future, perhaps we can discuss with Lang and the larger community about whether such a class makes in LLVM as well.  Maybe there's a way to get both checked and unchecked errors into LLVM using a single consistent interface.  But at least then the person who generates the error is responsible for deciding how important it is.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
BTW, I don't think the comment Lang cited had to do with replacing the errors with some other error backend.  It was more intended to handle a problem that came up with gdb where we tried to multiplex all various system error numbers into one single error.  lldb errors have a flavor (eErrorTypePosix, eErrorTypeWin32, etc) which allows you to use each native error number by annotating it with the flavor.  <br></blockquote><div><br></div><div>FWIW, using the llvm::Error model, the way this is handled is by doing something like this:</div><div><br></div><div>return make_error<WindowsError>(::GetLastError());</div><div><br></div><div>return make_error<ErrnoError>(errno);</div><div><br></div><div>but it is general enough to handle completely different categories of errors as well, so you can "namespace" out your command interpreter errors, debug info errors, etc.</div><div><br></div><div>return make_error<CommandInterpreterError>("Incorrect command usage");</div><div><br></div><div>return make_error<DWARFFormatError>("Invalid DIE specification");</div><div><br></div><div>etc </div></div></div>