[Development] QFile: writing via a temporary file

Oswald Buddenhagen oswald.buddenhagen at nokia.com
Mon Jan 9 12:14:47 CET 2012


On Fri, Jan 06, 2012 at 07:13:00PM -0200, ext Thiago Macieira wrote:
> On Friday, 6 de January de 2012 21.27.20, David Faure wrote:
> > Exception handling is a new argument though. But doesn't the current QFile 
> > have the exact same issue then? You start writing, throw an exception, dtor 
> > calls close, there you go. The use of an internal temporary file doesn't
> > change this at all, so I don't see why it should behave differently.
> 
> The file will be closed no matter what, unless you allow for the file descriptor 
> to leak. And even if it were to leak, the writing was already done and has 
> appeared on disk.
> 
> That's very different from executing a rename upon closure. Up until that 
> point, any observers of the file have not seen any change. Then they do and see 
> an in-progress change being saved.
> 
i agree with that.

> No, whatever this class is, close() without commit() means "rollback".
> 
that would make it pointless to have this as a built-in feature of
qfile, because the api would be inconsistent anyway (qfile => close,
qsavefile => commit).

anyway, i don't buy the exception argument. i don't see why the d'tor
needs to continue calling close() - it can call rollback() instead just
as well. for non-safe qfiles this is the same as close(), so existing
behavior doesn't change.



More information about the Development mailing list