Article of interest: Python pros/cons for the enterprise

[Jeff Schwab]

Matthew Woodcraft wrote:
> Jeff Schwab  <jeff at schwabcenter.com> wrote:
>> Matthew Woodcraft wrote:
>>> I see. Then, unless you don't care about data loss passing silently,
>>> this 'most traditional' way to open a file is unsuitable for files
>>> opened for writing.
> 
>> No, why would you think so?  If you want something special to happen 
>> when the close() fails (as you indeed would if you were writing 
>> important data), you have to say somehow that you want your special code 
>> called.  What syntax would you like to see?  Here's what the C++ would 
>> look like, supposing you have a type LoggingCloser that calls close and 
>> logs any failure:
> 
> Sure, but this LoggingCloser isn't what you described as the 'most
> traditional, easiest way to open a file in C++'.

It's not there to open the file, it's there to check the error code on 
close.  That's what you said you wanted.


> The more general point is that, where you want to take action on
> cleanup and you need to handle errors from this action, it usually
> isn't enough to have one class per type of resource which knows what
> clean up action is required (because the required response to the error
> usually varies).

If there is variation, you can either pass some data to the responsible 
object's constructor, or you can give it "policies" for what to do in 
different situations.

http://en.wikipedia.org/wiki/Policy-based_design


> Additionally, in languages where exceptions are the usual way to report
> errors but exceptions from destructors are not managed pleasantly, the
> error recovery code can't use the language's normal mechanisms for
> dealing with the error response.

Huh?  Why not?