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.
