Mac Apps That Use Garbage Collection Must Move to ARC

[via Digitalmars-d]

On Friday, 27 February 2015 at 15:53:18 UTC, ponce wrote:
> On Thursday, 26 February 2015 at 14:22:01 UTC, Ola Fosheim 
> Grøstad wrote:
>>> No. If I can't open a file I'd better not create a File 
>>> object in an invalid state. Invalid states defeats RAII.
>>
>> This is the attitude I don't like, because it means that you 
>> have to use pointers when you could just embed the 
>> file-handle. That leads to more allocations and more cache 
>> misses.
>>
>
> I really don't understand how any of this is related to what we 
> were previously discussing: error handling.

You wrote:

«No. If I can't open a file I'd better not create a File object in
an invalid state. Invalid states defeats RAII.»

If you embed the File object in other objects you also have to 
deal with the File object being in an invalid state. The 
alternative is to have discrete objects and nullable pointers to 
them. Makes sense for a high level programming language like  
Java, makes no sense for a system programming language.

> It does't make much sense to go on after an error, in any 
> software that want some reliability.

It does, when you do async buffering and want performance, e.g. 
OpenGL.

Often it also makes error-handling simpler. Often you don't care 
about when it failed, you often only care about the 
"transactional unit" as a whole.

It also makes programs more portable. There are big architectural 
differences when it comes to when errors can be reported. E.g. 
you don't want to wait for a networked drive to respond before 
going on. You only want to know if the "closing of the 
transaction" succeeded or not.