Re: Exception Misconceptions: Exceptions are for unrecoverable
errors.
On Dec 24, 10:56 am, peter koch <peter.koch.lar...@gmail.com> wrote:
On 23 Dec., 23:51, Kaz Kylheku <kkylh...@gmail.com> wrote:
On 2009-12-22, James Kanze <james.ka...@gmail.com> wrote:
And there can be other issues besides leaking. In the
end, you've got to ensure internal consistency for all
possible control flows. When some of the possible control
flows are the result of an exception, then this
requirement is called exception safety.
Right; for instance failing to unlock a mutex, or roll back
a transaction, aren't resource leaks.
Yes it is. A mutex held is also a ressource, and so is a
transaction. Both should be wrapped in a class having
appropriate destructor semantics.
A mutex probably should be considered a resource, but a
transaction? If the transaction is really a concrete object,
perhaps, but what if it is just an invariant that is temporarily
broken. (A good example of this would be a simple
implementation of shared_ptr. Boost goes to a lot of effort to
ensure that shared_ptr always leaves the program in coherent
state, but given that there are two dynamic allocations
involved, it requires careful consideration to ensure exception
safety.)
--
James Kanze