Re: Controlled types and exception safety

[Maciej Sobczak <no.spam@no.spam.com>]

tmoran@acm.org wrote:
>>But X := Y overwrites X before calling Adjust on it, so you can't store
>>the backup copy, or any way of accessing the backup copy, in X.
> 
>   Right.  But Adjust, in case of problems, could still find the copy of
> the old X in the "to be deleted" backup queue and restore X from there.
>   I didn't say this was nice, just that it was possible. ;)

Except that it doesn't solve anything. The whole issue with this 
commit-or-rollback implementation is that it should not just suppress 
the exception and pretend that nothing happened - it should guarantee 
the old state and at the same time let the exception fly out to the 
place where it could be actually handled, whatever that means in the 
given context. I've started with the assumption that function ":=" is 
allowed to fail - in the sense that it can raise exceptions. It's not, 
and therefore there is no point in implementing any failover features in 
it. It has to either guarantee the success or not be provided at all and 
the type should be limited.

This brings me to the next problem. Let's say that I provide a separate 
procedure Duplicate or Copy or Assign or whatever with the 
commit-or-rollback guarantees for some type (like Stack). Now, some of 
the types in my program will have ":=" for assignment, and some others 
will have the Copy procedure, but not ":=".
I want to create a generic container or some other component that will 
copy things around internally. It has to use ":=" for some types (like 
Integer) and Copy for others (like Stack).
In C++ I solve this problem (aside the fact that there is no problem in 
the first place) with template type traits or some other application of 
template specializations.
What about Ada?

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/