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

[Lang Hames via llvm-commits]

Hi Rafael,

>  static const char *ProgramName;
> >
> > -static int Error(const Twine &Msg) {
> > +static int ErrorAndExit(const Twine &Msg) {
> >    errs() << ProgramName << ": error: " << Msg << "\n";
> > -  return 1;
> > +  exit(1);
> >  }
>


This can now return void.


Thanks for catching that. Fixed in r265451.

- Lang.


On Tue, Apr 5, 2016 at 1:10 PM, Lang Hames <lhames at gmail.com> wrote:

> 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/497477b1/attachment.html>