Re: Exception Misconceptions: Exceptions are for unrecoverable errors.
"James Kanze" <james.kanze@gmail.com>
A mutex probably should be considered a resource, but a
transaction?
Sure. Actually I tend to replace the R in mozaiks from "resource" to
"responsibility". So everything looks uniform, resource alloc comes wih
responsibility to dealloc, mutex lock requires unlock, transaction opening
requires rollback or commit...
So you use the same tech -- the destructor sits there to carry out the
responsibility that is left over.
If the transaction is really a concrete object,
perhaps, but what if it is just an invariant that is temporarily
broken.
For API-based transactions it is simple, call BeginTrans, and keep a bool to
track explicit Rollback or Commit was called.
For internal state transactions it is more complicated -- you record the
stepst taken so rollback can be arranged. Though that is the less suggested
method, I try to use create-then-swap wherever possible.
(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.)
Err, what is that "lot effort"? Placing allocations into local scoped_ptrs
then swap or relase them into members afterwards?