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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development