On Wed, May 10, 2017 at 8:33 PM Lang Hames <lha...@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
