[Development] QFile: writing via a temporary file

[Craig.Scott at csiro.au]

On 09/01/2012, at 10:14 PM, Oswald Buddenhagen wrote:

> 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.

If I understand you correctly here, you are saying that the destructor could check the result of uncaught_exception() and if it returns true, the destructor would call rollback(), but if it returns false, it would call commit()/close() to save the changes? That would seem a nice compromise and lead to safer file handling.


--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia