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 <ztur...@google.com> wrote:
> On Mon, May 1, 2017 at 5:27 PM Jim Ingham <jing...@apple.com> wrote:
>
>>
>> > On May 1, 2017, at 4:52 PM, Zachary Turner <ztur...@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.
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
