[lldb-dev] Renaming lldb_private::Error

Zachary Turner via lldb-dev lldb-dev at lists.llvm.org
Mon May 1 17:33:07 PDT 2017


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


More information about the lldb-dev mailing list