automatic resource management for try/catch/finally statement for C# (duplicate for https://github.com/dotnet/roslyn/issues/4005, c# only)

[jmaine]

Be able to use a try/catch/finally block like a using statement in c#
Example C#:

try (var v = new Resource()) 
{

}
catch (Exception e)
{

}
finally
{

}

• The v variable is only in scope between the two braces just after the try.
• The catch block will catch any exception of the specified type from the code between the braces just after the try statement and the implicit call to Dispose()
• Dispose() will always get called even if an exception is called.
• If both the block after try and Dispose() throw an exception, we aggregate the exceptions in some way. e.g. ex.AddSuppressed(exceptionFromDispose) or ex.Data["SuppressedException"] = exceptionFromDispose;
• try with resources would be a legal syntax without either catch or finally. (in this case used to capture suppressed exceptions)

[bondsbw]

I like try with a statement (instead of requiring a block), then you get this for free:

try using (var v = new Resource ())
{

}
catch (Exception e)
{

}
finally
{

}

This still uses the term using, which I think is important to indicate the IDisposable pattern.

[jnm2]

You can only manage a single resource per try that way. Why would it not be just as good to decouple the two concerns and do this:

using (var v = new Resource())
    try
    {

    }
    catch (Exception e)
    {

    }
    finally
    {

    }

[john-cd]

@jnm2

You use the syntax that already exists for using:

 try using (Font font3 = new Font("Arial", 10.0f),
                        font4 = new Font("Arial", 10.0f))
            {
                // Use font3 and font4.
            } 

An alternative would be to allow catch and perhaps finally blocks in the using pattern:

using (var mydisposable = ...)
{
}
catch ( ...)  // optional
{
}
finally { ... }  // optional
// implicit finally that dispose the resources

We will need to think about the scope of the using / try variables: should they extend to the try and/or finally blocks?

[jnm2]

Okay but I'm still wondering why this proposal is worth the work and added complexity over what we have today:

using (var v = new Resource())
try
{

}
catch (Exception e)
{

}
finally
{

}

Is it really so much of a gain to lose the try line?

[HaloFour]

@john-cd

That would force using to require a block in order to avoid ambiguity with nesting. That would mean that using could only conditionally support being followed by an embedded-statement which I think would be confusing.

I largely agree with @jnm2, we can achieve this functionality with the syntax we have today. A single additional keyword is not overly verbose. But I also wouldn't mind Java's TWR syntax of specifying resources immediately after try. In Java the resource is "closed" prior to catch and finally statements and is no longer in scope.

[john-cd]

Whatever the LDM decides should accomplish the following goals:

1- Simpler syntax with less nested { }

2- Avoid requiring the declaration of variables prior to the try { } catch { } finally { } block.
We often have to refactor a variable outside of a try block because of lack of scope in catch / finally.

3- Avoid the abuse of the using / IDisposable pattern as a context manager.

A fair amount of code e.g. in multithreaded programming implements IDisposable on classes that have nothing to do with resource management, just to guarantee disposal.

http://stackoverflow.com/questions/2101524/is-it-abusive-to-use-idisposable-and-using-as-a-means-for-getting-scoped-beha

[jnm2]

Avoid the abuse of the using / IDisposable pattern as a context manager.

I don't want to discuss this here because there's already a conversation in another thread, but using IDisposable for arbitrary scoping is not abuse.

[john-cd]

@jnm2 It is a bit of an ideological debate.

This said,
(1) using( ... ) for unit-of-work / scoping / transaction management requires writing an additional janitor class, implementing the IDisposable interface, etc...
(2) There are proposal to allow default methods in interfaces like IDisposable to automatically include protected Dispose(bool). That would pollute Intellisense in the scoping use case.
(3) The purpose of an IDisposable implementation is unclear, unless one inspects the Dispose method.

I wish there were a simpler way to do deterministic scoping / transactions e.g.

• creation of a second magic IScope interface distinct from IDisposable that works with using and/or try
• deterministic object cleaning mechanism (much larger debate)

[jnm2]

The purpose of an IDisposable implementation is unclear, unless one inspects the Dispose method.

I don't think I've ever had this experience, and I'm one of the more- shall we say, creative- IDisposable users. Do you know of an example of real-world ambiguity here?

[jmaine]

Whatever the LDM decides should accomplish the following goals:

1- Simpler syntax with less nested { }

2- Avoid requiring the declaration of variables prior to the try { } catch { } finally { } block.
We often have to refactor a variable outside of a try block because of lack of scope in catch / finally.

3- Avoid the abuse of the using / IDisposable pattern as a context manager.

I don't know about number two here. It may look be confusing.

[wanton7]

Instead of this I would prefer something like defer in golang that would run code after scope ends to avoid nesting. It would have much more wide range usage scenarios, not just for Dispose. Maybe something like

try
{
    var v = new Resource();
    defer v.Dispose();
    var v2 = new Resource2();
    defer v2.Dispose();
   // do stuff with v and v2
   // v2.Dispose is called here if there was no exception before defer v2.Dispose() line
   // v.Dispose is called here if there was no exception before defer v.Dispose() line
}
catch (Exception e)
{

}
finally
{

}

[john-cd]

Let me summarize the problems discussed above (and related issues) very explicitly, so that we could discuss:

1. It is generally not obvious which class implements IDisposable.

2. We often forget using with IDisposable objects, even if that is known

void Foo() 
{
var fs = File.Create(path);
// use fs
fs.Close();   // never called in case of an exception  
}

instead of

 using (FileStream fs = File.Create(path))
        {

        }

3. using is equivalent to

 {
              var fs =
              try
              {
                \\ use fs
              }
              finally
              {
                if (fs != null)
                  ((IDisposable)fs).Dispose();
              }
  }

There is no catch clause. To implement catch, we must either write by hand

   var fs = ...
   try
   {
    // use fs
    }
    catch( Exception)
   {
   // logs, rethrows 
   }
   finally
   {
                if (fs != null)
                  ((IDisposable)fs).Dispose();
   }

Common bug - forgetting the null check in the finally block.

Minor issue - some Disposable objects implement the interface explicitly, thus either a cast is required or a call to Close should be made.

The cleanest alternative syntax (as discussed above) is indeed

using (var v = new Resource(), ...)
try
{
}
catch (Exception e)
{
}
finally
{
}

but that is essentially a try within a try.
I wonder what the IL looks like though? Are there redundant instructions?

It also does not protect against exceptions in the resource's construction. To do that, one must write:

try
{
   using(resource)
   {
       //Do something here
   }   
} catch(Exception)
{
     //Handle Error
}

which is verbose.

4. Implementing the Dispose pattern for the resource disposal use case properly is tricky and verbose:

public class Stuff : IDisposable
{
 // some fields that require cleanup
    private bool disposed = false; // to detect redundant calls

public void Dispose()
{
    Dispose(true);
    GC.SupressFinalize(this);
}

protected virtual void Dispose(bool disposing)
{
    if (!disposed)
    {
        if (disposing)
        {
            // Dispose managed resources.
        }

        // There are no unmanaged resources to release, but
        // if we add them, they need to be released here.
    }
    disposed = true;

    // If it is available, make the call to the
    // base class's Dispose(Boolean) method
    base.Dispose(disposing);
}

}

The implementation can be trickier if a finalizer is required:

https://www.codeproject.com/Articles/15360/Implementing-IDisposable-and-the-Dispose-Pattern-P

noting that implementing a finalizer can have drastic impact on GC performance.

Common problem: every entry point into the class needs a guard to check whether or not the object has been disposed.

5. using( ... ) for unit-of-work / scoping / transaction management requires writing an additional janitor class, implementing the IDisposable interface, etc...

Taking the examples from another thread,

private void FiddleTheFrobble()
{
    this.Frobble.Unlock();
    try
    {            
        Foo();                  // Can throw
        this.Frobble.Fiddle();  // Can throw
        Bar();                  // Can throw
    }
    finally
    {
        this.Frobble.Lock();
    }
}

is often rewritten as

private void FiddleTheFrobble()
{
    using (var janitor = new FrobbleJanitor(this.Frobble))
    {            
        Foo();                  // Can throw
        this.Frobble.Fiddle();  // Can throw
        Bar();                  // Can throw
    }
}

where FrobbleJanitor looks roughly like

class FrobbleJanitor : IDisposable
{
    private Frobble frobble;

    public FrobbleJanitor(Frobble frobble)
    {
        this.frobble = frobble;
        this.frobble.Unlock();
    }

    public void Dispose()
    {
        this.frobble.Lock();
    }
}

which is verbose and splits the handling of Frobble into two classes / files.
Purists will point out that this code has nothing to do with GC / finalizers.

6. There are proposal to allow default methods in interfaces like IDisposable to automatically include protected Dispose(bool). That would pollute Intellisense in the scoping use case above.

7. The try pattern is used for other things than resource management - logging, inserting a closing tag in an HTML / XML stream, etc... It is legitimate to try to decouple the two concerns.

8. Wrapping code in a try { } catch { } finally { } often requires the declaration of variables prior to the try { } catch { } finally { } block. We often have to refactor a variable outside of a try block because of lack of scope in catch / finally.

var myHTML = new HTML();
myHTML.InsertStartTag();
// ...
myHTML.InsertEndTag();

becomes the verbose

HTML myHTML;        // refactoring: declaration outside of the block; explicit type declaration, not var
try {
   myHTML = new HTML();   // separate call to the constructor
  myHTML.InsertStartTag();
  // ...
}
catch(Exception) 
{ 
// ... 
}
finally 
{
   if (myHTML != null)
       myHTML.InsertEndTag();
}

[jnm2]

@john-cd Dispose(true) is only called by Dispose() and Dispose(false) is only called by the finalizer. If you have no finalizer, there is no reason to implement the Dispose(bool) method or call GC.SuppressFinalize. (Nowadays with SafeHandles, there should be no reason to implement a finalizer again.) I think this is state of the art:

public class Stuff : IDisposable
{
    // some fields that require cleanup
    private bool isDisposed = false; // to detect redundant calls

    public virtual void Dispose()
    {
        if (isDisposed) return;
        isDisposed = true;
        // Dispose managed resources, including SafeHandles which are managed resources and encapsulate their own finalizer and unmanaged resources
    }
}

[AdamDotNet]

I came here after I finally (har, har) got to use Java 7 on an Android project (phew, made it to 2011! Moved min SDK to 19 from 15) and got rid of my finally blocks for try with resources. I thought, dang, it looks like Java has using with catch blocks, why not C#? Then I saw the comments here, particularly @jnm2 suggesting:

using (var v = new Resource())
try
{

}
catch (Exception e)
{

}
finally
{

}

I guess the only inhibition is the compiler is nesting try/finally in a try/catch[/finally], but source code doesn't necessarily look like that, so maybe I just turn a blind eye? Also, Java try with resources can't put multiple resources in a single try ( ) like using can, and each try appears to require its own set of { } while using does not.

If something elegant can massage catching exceptions while using a using block, great. But this thread helped me conclude that Java's implementation isn't really better. Score: Java 0, C# 1,000,000.