Mac Apps That Use Garbage Collection Must Move to ARC
digitalmars-d at puremagic.com
Sun Mar 1 04:30:00 PST 2015
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
> I really don't understand how any of this is related to what we
> were previously discussing: error handling.
«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.
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.
More information about the Digitalmars-d