Proposal: catch finally, a finally that occurs only on exceptions

[lachbaer]

This is an extension that adds "exception based finally conditions".
Maybe a CLR change is needed.

Idea

The primary idea is to reduce code duplication in multiple occuring catch blocks, with respect to the corresponding exceptions.

This extends the common try-catch pattern, known by many other languages, and could serve as a role model for other languages as well.

Add a finally to the try-catch construct that is only called in case of an occuring (matching) exception.

StreamWriter sw = null;
try
{
    sw = new StreamWriter(pathToFile);
    {
        /* ... */
        // no exception occured up to here, 
        // so we can be sure that the stream exists and is open
        sw.Close();
    }
}
catch (IOException ioex)
{
    Logger.Log(ioex);
}
catch (UnauthorizedAccessException uaex)
{
    // TODO: Tell user, that file is unaccessable
}
finally (Exception ex)
{
    // this finally is executed _after_ any catch, _before_ standard-finally
    // like with catch, the exception parameter must be matched. 
    if (sw != null)
        sw.Close();
}
finally
{
    // this is a common traditional finally, called always at the very end
}

(Btw, this example is only made up! ;-)

[huoyaoyuan]

You could wrap the resource in a using statement, and jump out(or just return) in catch statement.
This does not need much work, and I think it's not worth to make quite a big change.

[lachbaer]

@huoyaoyuan

You could wrap the resource in a using statement

It's not about this specific problem but about a further development of the try-finally-catch philosophy.

[DavidArno]

@lachbaer,

The problem I see here is that by far the most common use case for finally was to handle closing resources. using handles that just fine these days:

try
{
    using (var sw = new StreamWriter(pathToFile))
    {
        /* sw will be closed */
    }
}
catch (IOException ioex)
{
    Logger.Log(ioex);
}
catch (UnauthorizedAccessException uaex)
{
    // TODO: Tell user, that file is unaccessable
}
finally
{
    // this is a common traditional finally, called always at the very end
    // (though it's unlikely to be here in reality
}

For this to be a compelling new feature therefore, it needs a good use-case that using can't handle.

[huoyaoyuan]

@lachbaer The dispose pattern is introduced for doing clean-up too, and I don't think anything is necessary to be put in finally (Exception ex) instead of the end of catch (Exception ex), unless it's clean-up for possible failure in the catch block. But in this case, you should do another try in the catch block.
Dispose and using are designed robust to call on null or anything already closed, so that they can use a single finally. Following this philosophy, I cannot imagine more usages for this proposal.

[AdrienTorris]

I find this very confusing. Excluding to speak about the bad example (use a using or dispose the StreamWriter in the finally), an implement like this can create a try with 4 or 5 catch and 5 or 6 finally, it's just hard to understand and to maintain. And I don't find what stuff you can do in a exception's finally that you can't/have to do in this exception's catch. And I don't see the point to handle a same exception in several code blocks.
If you have something to do in the case of a specific exception, that is why the catch exists for.
If you have something to do to dispose some resources, or other common logic, that why the finally exists for.
I don't see the point to merge this two elements, to me it just adding an useless complexity.

[AdrienTorris]

PS: I written about the example that is a bad one because of this :
- The developer took the decision to not use a using block
- The developer took the decision to not dispose the resources in the finally block

To me this two decisions are bad design decisions, and bad decisions have to be fix by the developer and not by the framework.

I understand that this issue is not about this specific example but we need to provide some good ones to prove that this multiple finally blocks could be usefull in some situations, and they are not just catch blocks duplications, and this example isn't speak in favour of this proposal.

[jveselka]

I think this use-case is actually useful. Its quite often I need to have special handling for different kinds of exceptions and than common (logging) code for all of them. However, you can achieve it today by putting common code in exception filter. The semantics are a bit different - common code executes before, not after, specific code - but in most cases it does not matter.
Your example could look like this

StreamWriter sw = null;
try
{
    sw = new StreamWriter(pathToFile);
    {
        /* ... */
        // no exception occured up to here, 
        // so we can be sure that the stream exists and is open
        sw.Close();
    }
}
catch (Exception ex) when (((Func<bool>)(() =>
{
    // this is executed BEFORE any catch but only if matching exception is thrown
    if (sw != null)
        sw.Close();
    return false; //return false is essential so other catch clauses are tried
})).Invoke()) { }
catch (IOException ioex)
{
    Logger.Log(ioex);
}
catch (UnauthorizedAccessException uaex)
{
    // TODO: Tell user, that file is unaccessable
}
finally
{
    // this is a common traditional finally, called always at the very end
}
  //special handling if file is malformed
}
finally
{
  //dispose of streams
}

[DavidArno]

@zippec,

catch (Exception ex) when (((Func<bool>)(() =>

That is one awesome "hack". I so wish I'd thought of that! 😀

[omariom]

Interesting that CLR already supports fault clauses.

[ajtribick]

One possible use case I can see for a feature like this would be in factory methods that return IDisposable types, or constructors that assign IDisposable fields. These require that the object not be disposed in the case of no exceptions thrown. This case is not handled by using which always disposes regardless of whether or not an exception has occurred. Example:

public DisposableType MakeDisposable()
{
    var foo = new DisposableType();    
    try
    {
        // Do some stuff with foo that may throw exceptions
        return foo; // We don't want this to be disposed
    }
    fault
    {
        // Exception occurred, bail out!
        // Consumer won't have access to foo, so it's our responsibility to dispose it
        foo.Dispose();
    }
}

Currently this can be emulated to a certain extent by catch-and-rethrow, but this affects the stack trace and requires duplication if certain exception types get special-cased.

[jnm2]

@ajtribick Workaround I use:

public DisposableType MakeDisposable()
{
    var foo = new DisposableType();
    var success = false;
    try
    {
        // Do some stuff with foo that may throw exceptions
        success = true;
        return foo; // We don't want this to be disposed
    }
    finally
    {
        if (!success)
        {
            // Exception occurred, bail out!
            // Consumer won't have access to foo, so it's our responsibility to dispose it
            foo.Dispose();
        }
    }
}

[ajtribick]

@jnm2 - I don't particularly like the success variable approach because it is possible to forget a success = true; if you have multiple returns, which would manifest in odd behaviour at runtime. Also depending on how your code is used, I would guess that you might in some rare circumstances get really unlucky and have a ThreadAbortException occur immediately after the assignment but before the return (not sure how feasible that actually is, though).

[jnm2]

@ajtribick It's not my absolute favorite but it does the job. return Interlocked.Exchange(ref foo, null); may interest you.

If I remember right, a well-timed ThreadAbortException can have the same effect if it happens once this method returns, so it's really no safer:

using (var foo = AllocateFoo())
{
    // Use foo
}

Compiles to the equivalent of:

var foo = AllocateFoo();
// Oops, ThreadAbortException.
try
{
    // Use foo
}
finally
{
    foo?.Dispose();
}

Plus .NET Core has explicitly made thread abort hardening a non-goal.

[jnm2]

Plus, even this is susceptible IIRC:

Foo foo;
try
{
    foo = /* Oops, ThreadAbortException after the return but before the stloc */ AllocateFoo();
    // Use foo
}
finally
{
    foo?.Dispose();
}