[llvm] r264425 - [Object] Start threading Error through MachOObjectFile construction.

[David Blaikie via llvm-commits]

On Sun, Mar 27, 2016 at 9:51 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > Yeah - this will be pretty rare, and I want it to be ugly - nobody should
> > use a pre-checked error except for the error-as-out-parameter idiom.
> > Actually Error::errorAsOutParameter() sounds good. :)
>
> And even that is only for constructors, right? Otherwise one should
> use Expected.
>
> In fact, using an std::error_code (or equivalent) as a parameter of
> constructed always looked a bit odd IMHO. With good move constructors
> we should be able to have trivial private constructors and always use
> an static create method that returns an ErrorOr (or equivalent).
>

It is a bit weird - but, as you say, it was already weird - and these
migrations/error handling improvements can be a lot of churn already, so
it'll probably be helpful to not have to tackle those refactorings
simultaneously, but flag them for future cleanup with a clear API like this
(like migrating parts of the codebase to unique_ptr - those "release" calls
are an obvious place to go hunting for future cleanup where unique_ptr
hasn't been pushed through al the APIs)

& it's not always possible to solve with movement - some objects have
important in-memory identity of the object itself (in many cases, then, you
might have a factory that returns unique_ptr instead, or raw pointers from
a slab allocator, etc - but that's part of the problem: whether the type
should have baked in knowledge about the allocation scheme or not) & so
ctor fail is about all you can do.

- Dave


>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160327/f29c868d/attachment.html>