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

[Lang Hames via llvm-commits]

Hi Guys,

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


Yep (modulo the cases Dave mentioned). I expect the common pattern to be a
named constructor returning an Expected<Foo>, with Foo's private
constructor taking an Error& and using ErrorAsOutParameter.

- Lang.

On Sun, Mar 27, 2016 at 11:17 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> 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/20160405/75728a41/attachment.html>