[lldb-dev] Renaming lldb_private::Error

[Zachary Turner via lldb-dev]

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?  Then instead of Expected<T> you
could have WithDiagnostics<T> that enforces the proper semantics.

On Mon, May 1, 2017 at 5:33 PM Zachary Turner <zturner at google.com> wrote:

> On Mon, May 1, 2017 at 5:27 PM Jim Ingham <jingham at apple.com> wrote:
>
>>
>> > On May 1, 2017, at 4:52 PM, Zachary Turner <zturner at google.com> wrote:
>> >
>> > Yea, grouping the error and the result together is one of the most
>> compelling features of it.  It's called Expected<T>, so where we would
>> currently write something like:
>> >
>> > int getNumberOfSymbols(Error &Err) {}
>> >
>> > or
>> >
>> > Error getNumberOfSymbols(int &Count) {}
>> >
>> > You would now write:
>> >
>> > Expected<int> getNumberOfSymbols() {
>> >    if (foo) return 1;
>> >    else return make_error<DWARFError>("No symbols!");
>> > }
>> >
>> > and on the caller side you write:
>> >
>> > Error processAllSymbols() {
>> >   if (auto Syms = getNumberOfSymbols()) {
>> >     outs() << "There are " << *Syms << " symbols!";
>> >   } else {
>> >     return Syms.takeError();
>> >     // alternatively, you could write:
>> >     // consumeError(Syms.takeError());
>> >     // return Error::success();
>> >   }
>> > }
>> >
>>
>> Interesting.
>>
>> This pattern doesn't quite work for fetching symbols - maybe that really
>> is more suitable as a Status than an Error.  After all, number of symbols
>> == 0 is not necessarily an error, there just might not have been any
>> symbols (e.g. a fully stripped main); and I'm going to work on whatever
>> symbols I get back, since there's nothing I can do about the ones that
>> didn't make it.  I just want to propagate the error so the user knows that
>> there was a problem.
>>
>> Jim
>>
>
> Sure, that was just a made up example.  You could imagine that being some
> private function deep in the implementation details of a symbol parser,
> where you've got some header that's supposed to be N bytes, and
> getNumberOfSymbols() seeks to offset 42 and reads a 4 byte value and
> returns it, but the function sees that there's only 40 bytes in the header,
> so it's not that there's no symbols, it's that something is seriously
> messed up.
>
> In that case you could return an error such as this.
>
> Of course, the person who called this function can either propagate it,
> deal with it some other way and mask it, or whatever.  Mostly I was just
> trying to show what the syntax looked like for grouping return values with
> errors.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170502/8b1fd76d/attachment.html>