[lldb-dev] Renaming lldb_private::Error

Zachary Turner via lldb-dev lldb-dev at lists.llvm.org
Sun Apr 30 11:14:52 PDT 2017


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?
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170430/cebab6e9/attachment-0001.html>


More information about the lldb-dev mailing list