[lldb-dev] Renaming lldb_private::Error

[Zachary Turner via lldb-dev]

I'm probably going to be looking at submitting this this week, more likely
sooner rather than later.  If I can get it all working hopefully even
tomorrow.

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

> I suppose, but I'm not sure ErrorAnd captures the intended meaning very
> well.  In any case, that's not super important at this stage since this
> isn't on the immediate horizon.
>
> On Mon, May 1, 2017 at 5:43 PM Lang Hames <lhames at gmail.com> wrote:
>
>> Hi Zachary,
>>
>> ... Then instead of Expected<T> you could have WithDiagnostics<T> that
>>> enforces the proper semantics.
>>
>>
>> You mean something like an ErrorAnd<T>? Chris Bieneman floated that idea
>> for some libObject code but we haven't got around to implementing it. If it
>> were generically useful we could do something like that.
>>
>> Cheers,
>> Lang.
>>
>>
>> On Mon, May 1, 2017 at 5:36 PM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> 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/20170510/f9518da0/attachment.html>