Re: [Configobj-develop] Safe File writing in ConfigOb

[Michael F. <fuz...@vo...>]

On 21/11/2011 11:46, Gibhardt, Holger wrote:
> Dear Michael,
>
>> Ouch, not good. But if the attempt to write raises an exception, that can be
> caught with try / except, why does that>exception not stop execution? If the
> code blocks then it can't raise an exception. If it raises an exception then
> it isn't>blocked.
>
> now I understand your point and see, that I explained the crash not exactly:
> There is an exception, which comes from the python function "open". But, as I
> did not catch this exception, my program hung up.

That isn't how Python works, an unhandled exception causes program 
termination - so if your program is blocking when this exception is 
raised then something else is happening.

>> This seems like good code for your particular situation, but I don't think
> it's generally necessary. (The exception>handling masks the original error
> for example by reraising the exception as a GammaError.)
>
> O.k., using my defined "GammaError" is the way, we get a possible error to
> the user (giving him an information about a missing .ini-file).
The original exception contains the specific error message as to why the 
file couldn't be written. Your code (which I realise is just how you 
handle this particular problem and not necessarily what you are 
suggesting should go directly into ConfigObj) removes this error message 
and raises its own. As a general matter obscuring error messages like 
this is not helpful - which is part of the reason I prefer to let the 
exception be unhandled in ConfigObj and let *callers* of the code decide 
how to handle any exceptions.

>
> I think, this is a problem, which should be handled in configobj.py:
>
> You check at the beginning, if the filehandler yields a good result (what I
> called "safe"). But later, this is not done anymore: The file could be
> blocked by another application, could be deleted whatsoever. Then you have
> the "open" exception and you must find out, what was responsible for this
> exception.
It is fine for you to retry failed writes - but that is the decision for 
the people calling write (other people may want to handle the situation 
differently). So whilst I think your approach is fine I disagree that it 
should be built into configobj.

An interesting discussion anyway.

>
> File opening should be handled safe at any time like in standard C.

Standard C does not automatically retry failed writes :-)

All the best,

Michael Foord

> If you don't agree to my opinion, it's no problem.
>
> Best regards
>
> Holger
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Configobj-develop mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/configobj-develop
>


-- 
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html