Ooops. I have succeeded in being not so clear again. :-) For some
reason, I have an uncanny knack at that. :-(
OK, what I *really* meant had nothing to do with assignment operations and
copy operations in C#. They had more to do with the exception safety
guideline that reads similar to this:
"Do everything that could throw off to the side in a safe way. Once those
operations are completed successfully, then, and only then, commit changes
to the state of the system."
So, the assignment operator that I gave earlier was only an example of
what I mention above. An example from C++ that popped out of the top of
my head on the spur of the moment.
You can translate that into a method existing on any object that alters
the state of said object.
The jist is this...... in order to have the ability to write exception
safe AND exception neutral code while guaranteeing the state of the
system, one needs operations that are guaranteed never to generate
exceptions. Either that, or litter the code with error prone, and ugly,
try/catch constructs, which I try to avoid.
Thanks,
-Trey
> There are no copy constructors in C#, so how exactly would this be an
> issue?
>
> Assignment is never overloaded. So I don't think it can ever throw.
> Isn't the only reason that this is only a big hairy issue in C++ because
> you can't trust things like assignment not to throw?
>
> So if you want to assign a bunch of stuff you would just do this:
>
> temp1 = orig1.Clone();
> temp2 = orig2.Clone();
> temp3 = orig3.Clone();
>
> // If we were going to have thrown we
> // would have done by now.
> dest1 = temp1;
> dest2 = temp2;
> dest3 = temp3;
>
>
> If this does throw an exeception, it'll do so before it gets to the
> dest1 = temp1. If it gets that far it's not going to go wrong after
> that point. The assignment operator here just copies references, and I
> don't think that ever throws.
>
>
> --
> Ian Griffiths
> DevelopMentor
>
> ----- Original Message -----
> From: "Trey Nash" <[EMAIL PROTECTED]>
>
>> I'm back with another exception safety musing. Let me start by
>> stating that one of the goals of exception safety is to ensure the
>> integrity of the software in the face of exceptions. That being the
>> case, consider the following contrived C++ class.
>>
>> class MyClass
>> {
>> public:
>> MyClass();
>> MyClass( const MyClass& other );
>>
>> MyClass& operator=( const MyClass& other );
>>
>> private:
>> Foo* resource1;
>> Bar* resource2;
>> };
>>
>> Now, let's examine the usual implementation of the assignment operator
>> assuming some resource creator funcs:
>>
>> MyClass& MyClass::operator=( const MyClass& other )
>> {
>> resource1 = CreateFooFromCopy( *other.resource1 );
>> resource2 = CreateBarFromCopy( *other.resource2 );
>> return *this;
>> }
>>
>> The problem is that this is not exception safe. If we throw during
>> the call to CreateBarFromCopy(), 'this' is in an undefined state.
>> Generally, the way to address this is to rewrite the assignment
>> operator in terms of the copy c'tor:
>>
>> MyClass& MyClass::operator=( const MyClass& other )
>> {
>> MyClass temp( other );
>>
>> std::swap( resource1, temp.resource1 );
>> std::swap( resource2, temp.resource2 );
>> return *this;
>> }
>>
>> The key is in the std::swap. It is guaranteed, by the standard, never
>> to throw. Anything that could throw will happen in the c'tor of the
>> temp object. And that's OK, b/c, if that happens, at least this will
>> be stable. Only after all possibly throwing things happen, should we
>> mess with the state of 'this' and we should only mess with the state
>> in a way that is guaranteed not to throw.
>>
>> Now, the big question. ;-)
>>
>> How to achieve this same desired effect in C# WITHOUT having to
>> introduce try/catch blocks everywhere, IOW, in an EXCEPTION NEUTRAL
>> way.
>
> You can read messages from the Advanced DOTNET archive, unsubscribe from
> Advanced DOTNET, or subscribe to other DevelopMentor lists at
> http://discuss.develop.com.
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
