<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, May 10, 2017 at 8:33 PM Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Leaving 'Status' aside for now (the rename makes perfect sense), I'm basing my ErrorAnd / WithError naming suggestion on this comment:</div></div><div dir="ltr"><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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?</blockquote></div><div><br></div></div><div dir="ltr"><div>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).</div></div><div dir="ltr"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div></div><div dir="ltr"><div>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:</div><div><br></div><div>In pseudo-c++:</div><div><br></div><div><font face="monospace, monospace">// Parse my object file.</font></div><div><font face="monospace, monospace">auto ErrorAnd<ObjectFile> ObjAndErr = parseObjectFile(...);</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">// I claim that I'm willing to handle truncated objects, or objects</font></div><div><font face="monospace, monospace">// containing bad symbol </font><span style="font-family:monospace,monospace">indexes. If the object file contains errors</span></div><div><font face="monospace, monospace">// other than this I will bail out.</font></div><div><font face="monospace, monospace">if (auto RemainingErrors = handleErrors(ObjAndErr.takeError(),</font></div><div><font face="monospace, monospace">                                        [](const BadSymbolIndex &BSI) { ... },</font></div><div><font face="monospace, monospace">                                        [](const TruncatedObject &TO) { ... }))</font></div><div><font face="monospace, monospace">  return RemainingErrors;</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">// Ok, *now* I can access my object:</font></div><div><font face="monospace, monospace">auto Obj = ObjAndError.takeValue();</font></div><div><br></div><div>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.</div></div><div dir="ltr"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div></div><div dir="ltr"><div>The programmatic imperative is the key difference here.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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</div></div></div>