Re: Exception-Safe Copy Assignment - C / C++ / MFC Discussion Boards

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

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? Smile | :)

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..."
Big Grin | :-D

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. Confused | :confused:

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.
Big Grin | :-D

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?
Smile | :)

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

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

led mike wrote:
Whatever. You just keep thinking whatever you want, I no longer care.

Of course.
Smile | :)

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

Does led mike mean rollback is not needed in assignment operator if exception is thrown?

regards,
George

Yes. Though I don't know if is he or Scott Meyers Wink | ;)

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