Proposal: make using call Complete() on completing without an exception

[dsaf]

At the moment it is easy to forget to complete a transaction:

using (var scope = new TransactionScope())
{
    //Transaction work items...
    scope.Complete(); //MSDN: "Failing to call this method aborts the transaction".
}

What if there was a new ICompletable interface that would look and work like IDisposable but would only be called on a successful completion of a using block?

interface ICompletable
{
    void Complete();
}

using (var scope = new TransactionScope()) //New version implementing ICompletable.
{
    //Transaction work items...
}

Pre-emptive Q&A:

1. What if we want to do it conditionally? Switch to try-catch just like with IDisposable.
2. Wouldn't it affect the existing code? Yes it would, but is it a complete show-stopper for this?
3. Is this super-beneficial or generic enough? Not sure, so far I was only thinking about transactions.

[HaloFour]

@dsaf

Quite certain that with TransactionScope that the requirement to manually call Complete was intentional. It would be dangerous to have the transaction automatically committed.

There are a few other proposals here to expand unit-of-work scenarios with using or other syntax and this largely fits into that.

[dsaf]

@HaloFour one could argue that forgetting to commit a transaction or dispose of a resource is also dangerous as it could lead to data loss and memory leaks.

Sorry, I did not check for pre-existing issues. Maybe I should wait until the migration and cleanup of existing stuff is complete. Anyway, I think the trick is to not introduce new syntax if possible. Do you think it's worth closing this one based on all those other proposals?

[HaloFour]

@dsaf

There's #85 which is general purpose. Also a bit of conversation in #93 regarding using and unit-of-work in general.

[scottdorman]

Yes, calling Complete manually in the context of TransactionScope was intentional. Just because the using block completes successfully (meaning that no exceptions were thrown) does not necessarily mean that the transaction should be completed as there may be other things that have happened within that block which indicate that the transaction should be aborted.

Consider importing data from a flat file. This typically occurs in a loop and, more often than not, has some sort of "early bail out" mechanism so that if more than a given number of SQL failures occur the entire transaction is aborted so the user can fix their file without worrying about trying to figure out which rows were imported and which rows weren't.

In the case of TransactionScope specifically, I think an analyzer would be appropriate here that looks to make sure you're calling Complete and/or Abort somewhere in the code path.

[Thaina]

I was once propose return using syntax dotnet/roslyn#16958

Which also include custom disposal logic

I have an idea that we should have something like yield from IEnumerable that break function into pending block, return some object for use in upper stack, then continue after finish using that object

But my idea is, that syntax must enforce caller to explicitly make block scope to ensure that the cleanup(completion) must be called one way or another

To add transaction syntax to do this work might be a solution?

[dmitriyse]

Probably I created a duplicate. But this proposal have a little bit more capability - obtain exception.
#216

[dmitriyse]

After C# 8.0 release, I have revisited using operator improvements and created new proposal which is superset for this one. See, #3025