Re: exception safety / RAII ?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> I'm not sure I understand Jon Harrop's concern about using resources
>> after they've been deallocated.  This has been addressed in the obvious
>> way (return errors for operations on remaining references) in various
>> languages for decades, and unlike memory management and type errors,
>> AFAIK hasn't been a major source of bugs or complaints.

> A great deal of effort has been put into writing static verifiers to ensure
> correct use, in order to remove this class of run-time errors.  So I think
> this is unquestionably a source of bugs.

There are different kinds of bugs.  They can be common/rare, serious/benign,
hard/easy to find, hard/easy to fix, ...
Errors that have to do with things like "close" are generally easy to fix.
It's important to catch them, so we have things like Vault that try to catch
them statically.

> Could it not be said that having a GC is a way to avoid such errors in the
> context of memory allocation and deallocation?

In contrast, errors that have to do with leakage and/or dangling pointers,
are often hard to fix, requiring a considerable rework of the code.

Having a GC gives you a freedom when designing an API that is completely
incomparable to the minor convenience of not having to explicitly
close files.  Compare the success of C++ destructors to deal with
file-closing and the insufficiency of those same destructors to deal with
object deallocation (leading to the never ending use of reference counting
and/or explicit copying).


        Stefan