On 10. jan. 2012, at 02.39, ext craig.sc...@csiro.au wrote: > 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.
No, commit needs to be explicit because it *destroys* a previously known good state. Only the developer can know when it is safe to replace the old version with the new freshly saved one and he needs to make an explicit choice. QFile's destructor (or any destructor for that matter) shouldn't care at all about whether it is being called as part of stack unwinding due to exception or plainly going out of scope or being deleted. Cheers, João _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
