[lldb-dev] Renaming lldb_private::Error

[Pavel Labath via lldb-dev]

On 1 May 2017 at 19:48, Zachary Turner via lldb-dev
<lldb-dev at lists.llvm.org> wrote:
>
>
> On Mon, May 1, 2017 at 11:28 AM Jim Ingham <jingham at apple.com> wrote:
>> If it is actually causing confusion (I haven't experienced such yet) I
>> don't mind typing some extra letters.
>
> I think that's in part because llvm::Error isn't very prevalent inside of
> LLDB (yet).
I actually tried to use llvm:Error a couple of times, but I had given
up on it each time because it make all files which do "using namespace
llvm && lldb_private;" not compile because of the ambiguity, so I
welcome the rename wholeheartedly.


For me the biggest advantage of llvm::Error is the integration with
Expected<T>, avoiding the "do I make the Error the return value (and
return the *real* result by reference), or the other way around",
dilemma.

>
>>
>>
>> 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.
>
> 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.
>
> 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.
>
> 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.

I think Status is better than LLDBError, although the fact that we
will then have gazillion of declarations "Status error;" almost
counterbalances that.