[lldb-dev] Renaming lldb_private::Error

Mon May 1 11:28:51 PDT 2017

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.

If it is actually causing confusion (I haven't experienced such yet) I don't mind typing some extra letters.  

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.

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.  At some point we envisioned process plugins, for instance, being dynamically loadable.  If you had lldb working that way, when you dynamically loaded a process plugin for a system with a different error numbering scheme, you would also have to dynamically load the new error flavor.

Jim

> On Apr 30, 2017, at 11:14 AM, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> I think it should be fairly easy to keep interoperability with SBError. SBError just wraps an lldb_private::Error, so as long as we can construct some implementation of ErrorInfoBase from an SBError, we should be good to go. As an extreme example, we could keep LLDBError exactly as is and provide an ErrorInfoBase implementation that wraps it, but keep it around only for compatibility but be deprecated otherwise. Obviously we can do better than this, but the point is it's not a big obstacle 
> On Sun, Apr 30, 2017 at 10:41 AM Lang Hames <lhames at gmail.com> wrote:
> /// ...In the future we may wish to switch to a                                                                                                                                                 
> /// registration mechanism where new error types can be registered at                                                                                                                                              
> /// runtime instead of a hard coded scheme.
> 
> I immediately regret my decision to copy-paste from terminal. :/
> 
> - Lang.
> 
> 
> 
> On Sun, Apr 30, 2017 at 10:39 AM, Lang Hames <lhames at gmail.com> wrote:
> Hi Zachary,
> 
> I'm new to LLDB so take my opinion with a grain of salt, but this sounds like a good idea to me. LLDB is likely to encounter more and more LLVM APIs using llvm::Error in the future, so renaming lldb_private::Error to reduce confusion seems sensible.
> 
> Replacing lldb_private::Error at some point in the future probably makes sense too. The author of lldb_private::Error seems to have had a similar idea:
> 
> /// ...In the future we may wish to switch to a                                                                                                                                                 
> /// registration mechanism where new error types can be registered at                                                                                                                                              
> /// runtime instead of a hard coded scheme.
> 
> The challenge here will be interoperability with the python APIs, which look like they map the current lldb_private::Error into Python. That will take some thought, but I think it should be possible.
> 
> For any LLDB devs who are interested in llvm::Error, the lightning talk that introduced it is at: https://www.youtube.com/watch?v=Wq8fNK98WGw , and the API is covered in more detail in the LLVM programmer's manual: http://llvm.org/docs/ProgrammersManual.html#recoverable-errors .
> 
> Cheers,
> Lang.
> 
> On Fri, Apr 28, 2017 at 8:40 PM, Zachary Turner <zturner at google.com> wrote:
> I have a patch locally that renames lldb_private::Error to lldb_private::LLDBError.  As you might expect, this is a pretty large patch so I don't plan to put it up for review, but since it's kind of a fundamental class I figured I should at least start a discussion.
> 
> The primary motivation for this is to enable cleaner interop between lldb's Error class and llvm::Error.  Currently there is an ambiguity between the two.  Obviously they are scoped in different namespaces, but it's still confusing when looking at code to see such similarly named classes.
> 
> There are a number of advantages to llvm::Error over lldb Error which I'm happy to elaborate on if anyone needs some clarification (I've also cc'ed lang on here, who wrote the original llvm Error implementation).
> 
> Long term I would eventually like to deprecate lldb's Error class entirely, and switch entirely to llvm::Error.  An intermediate transition phase would likely involve making something like LLDBWrapError which interoperates with llvm::Error and wraps an lldb_private::LLDBError.
> 
> For now though, I'm only proposing a very simple rename with minimal invasiveness.
> 
> Comments?
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev