[llvm-dev] [RFC] Error handling in LLVM libraries.
Lang Hames via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 10 20:42:06 PST 2016
Hi Mehdi,
Thanks for the +1, and for offering to help out with reviews. I really
appreciate that. :)
- Lang.
On Wed, Feb 10, 2016 at 8:07 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
> > On Feb 10, 2016, at 7:19 PM, Rafael EspĂndola <
> rafael.espindola at gmail.com> wrote:
> >
> >> In the long-term I expect many parts of LLVM may want to migrate from
> >> std::error_code to TypedError, but that's ultimately a decision for the
> >> maintainers of the respective parts. I'll be very happy to provide
> input and
> >> support, but I don't want to pre-empt anyone else's decision on whether
> to
> >> adopt this.
> >
> > That means we will forever have an incomplete transition.
> >
> > We still haven't finished moving to the "new" naming style. Moving to
> > the current path handling took from Nov 2009 to Jun 2013.
> >
> > I am still not convinced that the new system is better than a
> > asserting wrapper over std::error_code with diag handlers, but I don't
> > have the time to change Orc to use to show it. Given that I also
> > failed to convince you otherwise, we will probably have to go with the
> > view of who can actually code this.
> >
> > But *please*, make an effort to use it everywhere. We still have a mix
> > of bool+std::string, std::error_code and ErrorOr. Are each of these
> > better than what you are proposing in one case or the other? Probably.
> > Is it worth it having unique snow flakes? I don't think so.
> >
> > In particular, please don't change just the "MachO-specific part of
> > X". In the past I have made an effort to keep MachO bits current when
> > working in MC and lib/Object. Please do the corresponding effort. For
> > example, if you change llvm-nm, please change all of it
>
> FWIW, I support the effort Lang is leading, so it is a +1 on my side to
> move on!
> And I also agree with Rafael that it would be really better to limit as
> much as possible the mix of multiple reporting inside a component.
>
> Lang: please CC me on the reviews, I'll be happy to follow the development.
>
> --
> Mehdi
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160210/78d5d314/attachment-0001.html>
More information about the llvm-dev
mailing list