Article of interest: Python pros/cons for the enterprise

[Matthew Woodcraft]

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

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

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.

-M-