[lldb-dev] Renaming lldb_private::Error

[Zachary Turner via lldb-dev]

This is now done in r302872, btw.  I'm only able to test on Windows here,
but I didn't see any regressions (not sure why there would be), and there
were very few compilation failuers to fix up.  So hopefully other platforms
don't run into any problems

On Wed, May 10, 2017 at 9:02 PM Zachary Turner <zturner at google.com> wrote:

> On Wed, May 10, 2017 at 8:33 PM Lang Hames <lhames at gmail.com> wrote:
>
>> Leaving 'Status' aside for now (the rename makes perfect sense), I'm
>> basing my ErrorAnd / WithError naming suggestion on this comment:
>>
>> Is there any chance of introducing something like make_status<T>() into
>>> llvm/Error.h, that constructs the llvm::Error in such a way that it still
>>> interoperates nicely with everything else?
>>
>>
>> which contains a fundamental tension: Error's purpose is to be
>> un-ignorable, which could be considered "not nice", and is definitely at
>> odds with the idea of the user implicitly ignoring it if they want to
>> (though it can be explicitly ignored by calling consumeError).
>>
>> But if it does need to be handled (and as such is called an error), then
>>> I'm not sure if it makes sense to say there's also a value.  So ErrorOr, or
>>> Expected seems to convey that meaning in the only way possible.  If you
>>> don't get the thing you're expected to get, you need to handle the error.
>>
>>
>> This is an aside from the LLDB conversation, but worth noting: While
>> Error instances must be dealt with, that doesn't mean Error is only useful
>> for hard errors. Being good for diagnostics was part of its original design
>> brief. The ErrorAnd concept comes into play any time you have a data
>> structure that can be partially malformed but still useful. Consider
>> libObject, for example: It should be able to parse partially malformed
>> object files (ones that have been truncated, or contain bad symbol indexes,
>> or malformed symbols, etc.). However you want to make sure that the client
>> explicitly acknowledges any errors in the file before proceeding (that way
>> they can't claim later that you didn't warn them. ;). ErrorAnd<ObjectFile>
>> is a perfect fit for this. It would take an Error (which may be success, a
>> singleton Error, or a compound Error) and an ObjectFile, and force you to
>> consume the Errors before accessing the file:
>>
>> In pseudo-c++:
>>
>> // Parse my object file.
>> auto ErrorAnd<ObjectFile> ObjAndErr = parseObjectFile(...);
>>
>> // I claim that I'm willing to handle truncated objects, or objects
>> // containing bad symbol indexes. If the object file contains errors
>> // other than this I will bail out.
>> if (auto RemainingErrors = handleErrors(ObjAndErr.takeError(),
>>                                         [](const BadSymbolIndex &BSI) {
>> ... },
>>                                         [](const TruncatedObject &TO) {
>> ... }))
>>   return RemainingErrors;
>>
>> // Ok, *now* I can access my object:
>> auto Obj = ObjAndError.takeValue();
>>
>> Again, I'm not recommending this for any specific LLDB interfaces (I
>> don't know them well enough yet), but I believe it has its place as an
>> idiom.
>>
>> Right.  We know that at some point (at the least where they escape to the
>>> SB API's) we'll have to have a container for the content of the error which
>>> carries none of the programmatic imperatives we want to impose at lower
>>> layers.
>>
>>
>> The programmatic imperative is the key difference here.
>>
>> Actually, Zachary - it's just occurred to me that that's what you may
>> have been asking for: A type that's structured like Error, but without the
>> hard requirement that it be checked? If so you're right - that might be an
>> interesting thing to add to llvm/Error.h.
>>
>
> Pretty much.  That's what I'm referring to as Status.  An advisory as
> opposed to a mandatory error.  (Don't get me wrong, I like llvm::Error and
> use it heavily, I just think both have their place).   The trick is going
> to be how to make it so people *want* to default to the mandatory Error,
> and only use the advisory error when it's really important.  It might be
> tempting for people to say "yea I don't want all this ugly error checking
> code, I know what I'm doing" when really they should be using a mandatory
> Error
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170512/2916abfe/attachment.html>