|
<br />
try<br />
{<br />
temp = this->tx;<br />
this->tx = rhs.tx;<br />
}<br />
catch (...)<br />
{<br />
this->tx = temp;
throw;<br />
}<br />
The problem here is that the rollback operation might throw, too.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist
|
|
|
|
|
Hi led mike,
Then, how do you understand the statement "cannot in general roll back the change already made to t1_", why can not?
regards,
George
|
|
|
|
|
George_George wrote: the statement "cannot in general roll back the change already made to t1_", why can not?
I don't care why can't since you shouldn't anyway. It would be "bad practice" to do something like that (rollback) in an assignment operator because the user will not expect that outcome which then leads to errors that are difficult to locate. Again I highly recommend anyone that aspires to be more than a junior C++ developer reads Meyers Effective C++ books. The material he covers is far more valuable than knowing which register they keep the stack pointer in or how the VTable works.
led mike
|
|
|
|
|
Hi led mike,
If there is exception thrown in assignment operator, how do you ensure exception safety -- making all objects in consistent status without using rollback? Could you describe a solution with some pseudo code please? Refer a link to save typing is also fine.
regards,
George
|
|
|
|
|
George_George wrote: If there is exception thrown in assignment operator
Then don't do one. If you can't perform the activities required in an assignment operation without the possibility of an exception, then override the assignment operator as private to keep anyone from using it and implement the feature as a method. The method name should be descriptive like "Copy" or "SafeCopy" or something and would then be appropriate to perform any sort of operation you want with documentation of the pre/post conditions and alternate outcomes. In rare and unavoidable cases it is even appropriate for the documentation to state that in the case of an exception the state of the object is unknown.
When a user sees the method name "SafeCopy" he should be interested in reading the documentation to discover exactly what that means. This is not true for an assignment operator which carries an implicit contractual meaning.
led mike
|
|
|
|
|
I got your points, led mike!
regards,
George
|
|
|
|
|
George_George wrote: assignment is enough.
What if it throws again?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks CPallini,
Do you mean if assignment throws, we need some other public method from the class which could do rollback job without throwing again?
regards,
George
|
|
|
|
|
Yes and probably we haven't that option.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Why "probably", CPallini?
I quote what you said, and you should be sure about what you mean.
regards,
George
|
|
|
|
|
George_George wrote: Why "probably", CPallini?
It depends on T1 public interface, we don't know about.
George_George wrote: I quote what you said, and you should be sure about what you mean.
If you quote my words, you should include "that is going on his arrogant assumptions..."
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks CPallini,
Makes senses.
regards,
George
|
|
|
|
|
Since when is rolling back an inherent feature of an assignment operator? I don't remember seeing that in Effective C++ or anywhere else.
led mike
|
|
|
|
|
I think he means a logical concept of "rollback", i.e. keep the status of object consistent (e.g. original).
regards,
George
|
|
|
|
|
rollback is not consistent with the implied contract of an assignment. At least I'm pretty sure it isn't on the plant I come from. I'm not really sure where I am at this moment.
Have you read Meyers?
led mike
|
|
|
|
|
led mike wrote: At least I'm pretty sure it isn't on the plant I come from
Nuclear plant?
led mike wrote: Have you read Meyers?
Nope, chemistry [^] is not my favourite topic.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Thanks led mike,
Then, how do you understand the statement "cannot in general roll back the change already made to t1_", why can not?
regards,
George
|
|
|
|
|
led mike wrote: is rolling back an inherent feature of an assignment operator
Who said that?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
You did. "is not the whole scenario: it maybe also impossible to roll back"
CPallini wrote: You're interpretation is correct, but is not the whole scenario: it maybe also impossible to roll back becauseT1 class public interface simply doesn't allow it.
led mike
|
|
|
|
|
OK, if you throw, then you're going to leave Widget object in inconsistent state?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Ok and rolling back would be equal to inconsistent, not a solution to it.
led mike
|
|
|
|
|
led mike wrote: Ok and rolling back would be equal to inconsistent, not a solution to it.
Why?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
a = 5;
a = 12;
Now you expect the value of a to be 12, period. If it were 5 it's inconsistent since you don't expect it to be 5 any more than you expect it to be some random value due to an exception being thrown.
However I strongly suggest you buy and read Meyers[^] on Effective C++ and More Effective C++, I am a consumer not an author.
led mike
|
|
|
|
|
Off course you made an example using built in types, not complex objects.
Anyway I'll probably follow your suggestions, the books look interesting.
BTW a random value is not an inconsistent state for int .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Whatever. You just keep thinking whatever you want, I no longer care.
led mike
|
|
|
|