Simplification of the finally block.

[EshG]

While explicit finally blocks are sometimes necessary, many use cases only require cleanup logic at the end of a method's scope. In such cases, resource cleanup is structurally simple, yet it must be expressed using try/finally, which is primarily an exception-handling construct.

This often leads to repetitive try/finally constructs that could be made implicit.

This proposal explores two variations that aim to simplify this pattern while preserving the semantics and guarantees of finally.

There has been prior discussion around try/finally generation in the context of using (for example, a proposal to suppress the generated finally block). That discussion focuses on avoiding finally for performance or safety reasons, whereas this proposal focuses on improving the expressiveness and ergonomics of finally while preserving its guarantees.

This form moves the finally outside the method block, preserving the familiar try { } finally shape without requiring an explicit try block around a single statement.

 internal async Task DoSomething(CancellationToken cancellationToken)
 {
     await Semaphore.WaitAsync(cancellationToken);

 } finally Semaphore.Release();

Similar to the blockless using statement, this form treats finally as a statement and supports multiple protected statements.

 internal async Task DoSomething(CancellationToken cancellationToken)
 {
     await Semaphore1.WaitAsync(cancellationToken);
     await Semaphore2.WaitAsync(cancellationToken);
     double d = 0;
     finally Semaphore1.Release();
     finally Semaphore2.Release();
 }

Extends the previous example with more complex control flow, illustrating nesting and the grouping behavior of multiple finally clauses. The equivalent lowered form is shown below.

 internal async Task DoSomething(CancellationToken cancellationToken)
 {
     double d = 0;
     await Semaphore1.WaitAsync(cancellationToken);
     if (d == 0)
     {
         await ConditionalSemaphore.WaitAsync(cancellationToken);
         finally ConditionalSemaphore.Release();
     }
     bool boolInsideTry = false;
     await Semaphore2.WaitAsync(cancellationToken);
     await Semaphore3.WaitAsync(cancellationToken);
     // `finally` clauses in the same context are grouped
     // into a single `finally` block in the lowered form.
     finally Semaphore1.Release();
     finally Semaphore2.Release();
     // A statement between grouped `finally` clauses starts a new nested protected region.
     int nestedInteger = 0;
     finally Semaphore3.Release();
     await OtherSemaphore.WaitAsync(cancellationToken);
     return;
     // This `finally` still executes when control leaves through `return`.
     finally OtherSemaphore.Release();
 }

The above sample is equivalent to:

internal async Task DoSomething(CancellationToken cancellationToken)
{
    try
    {
        double d = 0;
        try
        {
            await Semaphore1.WaitAsync(cancellationToken);
            if (d == 0)
            {
                try
                {
                    await ConditionalSemaphore.WaitAsync(cancellationToken);
                }
                finally
                {
                    ConditionalSemaphore.Release();
                }
            }
            bool boolInsideTry = false;
            await Semaphore2.WaitAsync(cancellationToken);
            try
            {
                await Semaphore3.WaitAsync(cancellationToken);
                int nestedInteger = 0;
            }
            finally
            {
                Semaphore3.Release();
            }
        }
        finally
        {
            Semaphore1.Release();
            Semaphore2.Release();
        }
       
        await OtherSemaphore.WaitAsync(cancellationToken);
    }
    finally 
    { 
        OtherSemaphore.Release(); 
    }

    return;
 }

[ufcpp]

#513 ?

[EshG]

I wasn’t aware of the defer discussion, It is an interesting mechanism, and there is certainly overlap in intent, in the sense that both approaches address scope-exit guarantees.

However, The defer proposal introduces a new mechanism for scheduling actions to run at scope exit. This proposal does not introduce a new mechanism, but instead extends the existing semantics to reduce the ceremony required to express them.

[TahirAhmadov]

The third code snippet in particular is hard to read. I would want that to stay in the current form, if it was code I had to maintain.

[HaloFour]

They're also not equivalent. For example, in the original version if Semaphore1.WaitAsync throws then the finally block with Semaphore3.Release would never execute because it never reached that scope. But in the new version the flattened finally blocks don't have a scope except for the containing block, which is the entire method in that case. In cases where the finally block depends on something to happen first you absolutely need that appropriate scoping. Anecdotally, given I rarely have try/finally blocks that span an entire method I don't see a lot of utility for a feature like this.

[EshG]

That’s a fair point. The third example is intentionally dense, as it demonstrates how the construct behaves under more complex control flow (nesting, grouping, and interaction with other statements).

The proposed change is mainly aimed at simpler
cases with one or a few finally statements. In more complex scenarios, the existing try/finally structure may still be preferable.

[EshG]

They're also not equivalent. For example, in the original version if Semaphore1.WaitAsync throws then the finally block with Semaphore3.Release would never execute because it never reached that scope. But in the new version the flattened finally blocks don't have a scope except for the containing block, which is the entire method in that case. In cases where the finally block depends on something to happen first you absolutely need that appropriate scoping. Anecdotally, given I rarely have try/finally blocks that span an entire method I don't see a lot of utility for a feature like this.

The semantic point is a good catch. On the utility side, I think that may depend quite a bit on coding style. In smaller methods, I do often see try/finally regions that cover most of the method body, which is also part of what makes blockless using useful. So I do think there is a meaningful class of cases where the cleanup scope is simple, but the current syntax is still fairly ceremonial.

[HaloFour]

I think it creates a big complication in the design though given what you need to do in the finally block very likely depends on what happened in the block up until that point. For example:

void M() {
    var conn = CreateConnection("...");
    // do stuff
    finally conn.Close();
}

If CreateConnection failed, conn is never assigned and cannot be used. Does that mean the finally has to be aware of the flow of any/all variables referenced, or is that simply a syntax error? The former would be ... complicated, but the latter feels like it precludes probably the most common use case for such a feature.

Even though I dislike the concept, defer probably makes more sense as a result as it signifies the start of that scope and only references the same identifiers that are already in scope.

[EshG]

I think I understand the complexity you are pointing to. The issue is that in this form the finally only marks the end of the protected region, but not its beginning. That makes cases like assignment- or acquisition-dependent cleanup much harder to define correctly.

In that sense, defer is more plausible, since it explicitly marks the point at which the scope-exit obligation begins. An alternative would be to define additional semantic rules for where the protected region starts, but I agree that this would make the feature significantly more complicated and less attractive.

At this point, I think the idea is only really viable in the more limited form of the first snippet, where the protected region is the entire method body and the finally consists of a single statement. That is much narrower, but it would still remove a fair amount of ceremonial code.