[llvm-dev] [RFC] Error handling in LLVM libraries.

[Lang Hames via llvm-dev]

Hi Rafael,

> > 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.

I included that caveat because it's not my place to insist on adoption, but
it is my hope is that this system could eventually replace other
error-return systems in LLVM.

> 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.

I'm happy to take this approach, and I agree: having a consistent scheme
for error returns everywhere is ideal.

> 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

I'm also happy to do this.

It's neither practical nor prudent to try to re-write the world in one go,
so there's no escaping a transition period with some glue code. That's no
reason not to do this though, and assuming the community's experience with
the system is as positive as mine was with the prototype, I think we could
aim to move to this as an essentially universal error-return solution in
the future.

Cheers,
Lang.


On Wed, 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
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160210/eb7edd3d/attachment.html>