[lldb-dev] Renaming lldb_private::Error

[Lang Hames via lldb-dev]

Cool. This is just the rename portion, right?

Sorry I didn't respond to your last message too.

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.


Do you just mean that ErrorAnd isn't an especially nice name? I wasn't
entirely sure what make_status<T>(...) was supposed to do so I assumed it
was to create a pair of an Error and a T. If that's the case,
make_with_error<T>(T, Error) (and WithError<T>) might be better names?

Cheers,
Lang.


On Tue, May 9, 2017 at 8:58 PM, Zachary Turner <zturner at google.com> wrote:

> 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/d983990b/attachment.html>