Expose the fault IL feature

[Mrnikbobjeff]

In the IL standard we have the fault exception handling mechanism outlined. It is not currently available in C#, even though there are use cases for it. I would love to have language support for this to not have to fall back to IL weaving.
For details see II.19.6 Fault handlers

[svick]

Related previous discussions: #434 and dotnet/roslyn#14831.

Also, I think that when discussing a feature, it's important to understand what its use cases are, just saying they exist is not sufficient. So, what are the use cases?

[Mrnikbobjeff]

The problem prompting this ticket for me was the necessity to rethrow often in catch handlers after returning types requiring disposal, but only if an exception was thrown. I had to rethrow exceptions in certain catch handlers, which lead to quite a lot of code bloat. The fault handler is perfect for such a scenario, as it allows you to not rethrow the exception and still have a handler which is called on exceptions. I'll put a code sample up as soon as I can. Another indicator that there are valid use cases for this is is the fact that fault handlers are already emitted when yielding in a using block. The idea as far as I can tell is to not dabble with the exception by rethrowing but simply disposing on an error. Finally is not an option there as it would dispose too early.

[binki]

I am confused by your reasoning about finally. The fault handlers run before finally does.

My hack to reduce the amount of code in this situation is to use when. For example:

try {
  DoSomethingExceptional();
} catch when (new Func<bool>(() => {
  PerformUnconditionalExceptionAction();
  return false;
})()) {
}

Exposing the filter IL feature to C# does give you a lot of power to put things in the right place. Exposing fault would let you get the same effect without it looking hacky. But I am happy enough since there were a lot of things that couldn’t be done cleanly before filter (when) was added to C#.

P.S., I normally use a utility function to invoke lambdas which makes the above cleaner. A utility function could accept an Action and return false for you to make this even more succinct.

[jnm2]

finally is the option I use due to missing the fault feature. Better to introduce a variable than to rethrow an exception.

var disposable = new DisposableThing();
var success = false;
try
{
    SomethingThatCouldThrow();
    success = true;
    return disposable;
}
finally
{
    if (!success) disposable.Dispose();
}

If this happens a lot, I use a helper class to implement this pattern with using:

using var tempFile = OwnershipTracker.Create(new TempFile());

// Do stuff with the temporary file that involves reading from sources that may throw.
// E.g.:
using var file = File.Create(tempFile.OwnedInstance);
await stream.CopyToAsync(file, cancellationToken).ConfigureAwait(false);

return tempFile.ReleaseOwnership();

Implementation: https://gist.github.com/jnm2/2302a81f7b8797d9e59a84c69d1e12bf

[popcatalin81]

@Mrnikbobjeff why is the fault so much better than catch...throw;?
Assuming how this would be implemented in C# a typical comparison case would look like:

    try
    {
       /// do some wprk
    }
    catch
    {
        tran.Rollback();    
        throw;
    }

An with hypotetical fault

    try
    {
        /// do some wprk
    }
    fault
    {
        tran.Rollback();
    }

It does not look like a big improvement

• You cannot filter by exception type in a fault block
• You cannot inspect or make use of the exception object if a fault block

An the use cases or even potential performance improvements are questionable for the general case.

[Mrnikbobjeff]

finally is the option I use due to missing the fault feature. Better to introduce a variable than to rethrow an exception.

var disposable = new DisposableThing();
var success = false;
try
{
    SomethingThatCouldThrow();
    success = true;
    return disposable;
}
finally
{
    if (!success) disposable.Dispose();
}

If this happens a lot, I use a helper class to implement this pattern with using:

using var tempFile = OwnershipTracker.Create(new TempFile());

// Do stuff with the temporary file that involves reading from sources that may throw.
// E.g.:
using var file = File.Create(tempFile.OwnedInstance);
await stream.CopyToAsync(file, cancellationToken).ConfigureAwait(false);

return tempFile.ReleaseOwnership();

Implementation: https://gist.github.com/jnm2/2302a81f7b8797d9e59a84c69d1e12bf

This is definitely the cleanest possible alternative but still way worse than simply declaring a fault handler, as this basically emulates a fault handler without the ability to add catch handlers on a per case basis. @popcatalin81 is correct that this simple try block does not get better with a fault handler. Now consider a try block with several different catch handlers which may execute logic on an individual basis. Netiher answer does offer a solution here (Sure, you could pass in an action or something into the quoted answer but this would make the code even more convoluted). I will send my code sample as soon as I return from my vacation.

[canton7]

Couldn't you also do something like:

var disposable = new DisposableThing();
try
{
    try
    {
        Stuff...
    }
    catch (A a) { }
    catch (B b) { }

    return disposable;
}
catch
{
    disposable.Dispose();
    throw;
}

Sure it's still uglier than a fault handler, but it's not the worst thing in the world.

[Mrnikbobjeff]

I will quote from Bart de Smet's Blogpost on fault handlers(http://bartdesmet.net/blogs/bart/archive/2009/12/06/reader-challenge-fault-handlers-in-c.aspx , link insertion is broken in GitHub on mobile), he expressed some thoughts very concisely about the purpose of the fault handler:
"If an exception happens during [the try block], we end up in the finally block and come to conclude success was never set to true. This indicates an error happened, and we should handle the fault case. However, this technique can get a bit tricky when there are different paths exiting the try block: one could return from the enclosing method in various places, requiring the “success = true” code to be sprinkled around. This is exactly what exception handling was designed for: reducing clutter in your code that has to do with error condition/code tracking. So, we’re defeating that purpose."
Sure there are alternatives to the fault block, but they require state tracking and offer less composability than the underlying feature. Why do all that and expose yourself to programming errors when the feature is already there in the clr?

[jnm2]

Motivation

There are two downsides I'm aware of with the obvious contender, catch { throw; }:

• The debugger stops an extra time, redundantly, when the same exception that you just stopped for is being rethrown. To run into this while in the Visual Studio experience, you would need to have opted in per solution to "stop on caught exceptions." It's not the default; in any real-world debugging, however, I'm constantly opting into this. These extra debugger stops can slow someone down.

• Similarly, AppDomain.CurrentDomain.FirstChanceException fires again for the same exception. Certain logging tools use this even when not debugging, and it can pollute logs. However, this isn't the end of the world. Every await adds two more of these around any exception that comes through it.

Workarounds

If you care about these downsides in your own code, you can use finally with a flag. This comes at the cost of declaring an extra one or two variables:

var disposableThing = ...;
var forcedSuccessFlag = false;
try
{
    // ...
    var forcedVariable = new ThingThatMightThrow(disposableThing);
    forcedSuccessFlag = true;
    return forcedVariable;
}
finally
{
    if (!forcedSuccessFlag)
    {
        // Whatever cleanup, in case we don't actually return
        disposableThing.Dispose();
    }
}

I also saw an IIFE stuffed into catch when shared above, which may be another contortion that avoids polluting the debugging experience.

Alternatives

Debuggers could gain a new setting so that they only stop on throw; if you haven't just stopped for this same exception. This would improve the experience for 20+ years of existing code which uses rethrows, without the need to recompile using a new language feature in order to benefit. There's an analogous situation which this debugger setting could even be broadened to address. When many nested async state machines are rethrowing the same exception repeatedly, you're having the same poor experience as with manually-written catch { throw; } code.

Further notes

As long as you use throw; and not throw ex;, the stack trace is unaffected during the rethrowing on .NET Framework (checked back to 3.5) and .NET (checked back to 8.0).

fault { } would indeed not give you access to the exception object or filtering, but this is probably not a meaningful limitation. Use cases for fault are cleanup cases which are closely aligned with finally. The only difference is whether the cleanup should be unconditional or should be done only on failure. finally also has no access to the exception object or filtering, and this has not significantly limited its usefulness.

fault { } could have a performance edge over rethrowing, but exceptions are already understood to be expensive in any scenario that would be this sensitive to the difference.

Difficulty

try { } catch { } fault { } is already not valid code, so making fault a keyword in that location doesn't seem to pose difficulties.

In order to allow fault blocks in iterators and async methods, the compiler would need to update its state machine translation logic. At a wild guess, this doesn't sound very difficult given how similar it is in concept to catch { throw; } or finally with a flag.

Conclusion

As much as I love the idea of exposing a native IL capability to C#, the motivation feels pretty thin to me. There are a couple of workarounds to choose from, one of which is easy to read and write, catch { throw; }. The main drawback of this workaround is something that debuggers could eliminate anytime, improving the experience for all the code out there that already uses catch { throw; }, and perhaps addressing scenarios beyond this one (e.g. async state machine rethrows).

[binki]

I think the list of motivations should include readable flattened try/fault/catch/catch/finally blocks. Using catch { throw; } must be in a nested try/catch to get the fault semantics when using filtered catches. The IIFE with when is better than rethrow for this same reason.

try
{
    var undisclosedResource = GetResource();
    try
    {
        InitializeResource(undisclosedResource);
        return undisclosedResource;
    }
    catch
    {
        undisclosedResource.Dispose();
        throw;
    }
}
catch (IOException ex)
{
    throw new ApplicationSpecificException("Something happened.", ex);
}

With fault this could be:

ResourceType undisclosedResource = null;
try
{
    undisclosedResource = GetResource();
    InitializeResource(undisclosedResource);
    return undisclosedResource;
}
fault
{
    undisclosedResource?.Dispose();
}
catch (IOException ex)
{
    throw new ApplicationSpecificException("Something happened.", ex);
}

I must admit, I personally do not see a use case for fault yet. The above code is still basically using flags—just doing so more tersely by using null and null-coalescing member access. While I have written many IIFEs in when clauses, those almost all need the exception object, making it ineligible to use fault if I understand correctly. I'd like to see a use case which would actually benefit from a fault clause existing.

Also, wouldn't it be most natural for the fault clause to come after try and before the first catch clause? I thought that's when it would run.