Brendan Enrick

Daily Software Development

Returning From Inside a Using Statement

A while back I wrote a blog post regarding this topic. In that post I explain that it is safe to use a return statement inside a using block, because the using block will handle the disposing of the defined IDisposable object. This is one truly great ability of the IDisposable interface. It makes it very important to use in my opinion. The using block in combination is very nice, because it handles the disposal for you.

One of my commenter on that post asked me if I was certain that the return statement was safe. He asked this because he couldn't find it in the documents. He also asked me if I had any code showing that this behavior works as I claim it does. I quickly wrote this simple little piece of code which works to demonstrate this behavior.

In my example I have a few things. I have a class which implements IDisposable and all it does to dispose is to write to the console. I then wrote 3 methods which each create and instance of this class in a using statement. One class is normal; it returns after the using statement is complete. The other two end abruptly. One of them returns from within the using statement, and the other throws an exception within the using statement.

 

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Application Starting\n");

        Console.WriteLine("Before normal method");
        NormalMethod();
        Console.WriteLine("After normal method\n");
        
        Console.WriteLine("Before return method");
        ReturnFromMethod();
        Console.WriteLine("After return method\n");

        Console.WriteLine("Before Throw method");
        try
        {
            ThrowFromMethod();
        }
        catch (Exception ex)
        {
            Console.WriteLine("Caught the Exception: " + ex.Message);
        }
        Console.WriteLine("After Throw method\n");

        Console.WriteLine("Application Ending");
    }

    private static void NormalMethod()
    {
        using (MyDisposable myDisposable = new MyDisposable())
        {
            // do nothing
        }
        return;
    }

    private static void ThrowFromMethod()
    {
        using (MyDisposable myDisposable = new MyDisposable())
        {
            throw new Exception("This is the exception");
        }
    }

    private static void ReturnFromMethod()
    {
        using (MyDisposable myDisposable = new MyDisposable())
        {
            return;
        }
        Console.WriteLine("DO NOT WRITE THIS!!!");
        return;
    }

    class MyDisposable : IDisposable
    {
        #region IDisposable Members

        public void Dispose()
        {
            Console.WriteLine("I am disposing!");
        }

        #endregion
    }

}

This code returns the following result. In this screen shot you should notice that each time it calls the dispose method of the MyDisposable object.

 UsingStatementReturn

Give the code a shot in a console application, and you will see that the using statement cleans up disposable objects pretty nicely.

Download this sample code as a small C# console application here.

I hope you enjoyed this post. I would also like to thank Lambros for the good comment. I hope to get more feedback from you in the future.

Optional and Named Parameters in C#.... Finally

I've used Python a decent amount in the past. I enjoy the language and I've taught the language to non-computer science students at Kent State University. There are plenty of things that I really love about that language. I could write plenty of blog posts regarding how totally awesome python is. I tend to use it for quick little bits of code. I don't use too much Python for production code, but I do like a lot of the language features.

One of the big pieces of Python I enjoy is the ability to define a default value for a parameter in a method. This allows for optional parameters. Wonderful stuff. I hate having to make extra overloads to handle default parameters which pass in either the right ones or values specifying that the value is missing. Way too much handling just to handle this case.

Named parameters are also a lot of fun since you're able to specify which parameter you're passing. It works pretty well in Python. I don't know how useful it will be in C#, but it is a neat feature which doesn't add much complexity to the language.

In the session I am sitting in at the PDC I am listening to a speaker talking about how this is coming down the pipe for C#. I would guess C# 4.0 will include these features. Now I can finally get rid of all of the extra overloads. I can finally just have my default parameters. No more of the extra overloads or passing in missing values.

For a lot of code we want to allow for customization, but at the same time we want to be able to have default values since the 90% case doesn't require the customization. We need the ability to customize some, so these features in combination could allow a method with say 8 parameters have you specify 2 of them and then name the 3rd one you want to specify. This should help clean up code and allow us to be concerned only with the code which is currently important to us. No need to worry about all the extra parameters in the method that we don't care about.

Finally!!! I've been wanting default and named parameters for a looooong time.

Dynamically Typed Objects in C#

In the past the C# language obtained a new feature allowing it to declare variables as type "var". It didn't really do any dynamic typing though. For the most part the var is just there for developer convenience. Some people have complained about this in the past. Stating that C# 3.0 doesn't have dynamic types. The problem is that with that it is figuring out when compiling what type the variable is.

I am currently sitting in the Los Angeles Convention Center for the PDC 2008. I am watching a session on the future of C#. One of the interesting demos we're seeing in this is some of the new dynamic typing that is coming down the pipe. Variables are being defined with the type "dynamic" this is very cool because it is being figured out at runtime and not at compile time. It seems to be a very powerful ability of the language even in this early stage. Perhaps we'll see some new stuff from this some time soon.

Looks like they're combining the dynamic and var so they work very well together.

Throwing Away Return Values

So it probably took me 15 seconds to track down this error in my code, and those wasted seconds, while very minor, are exactly why I wish Visual Studio or ReSharper or some program would alert me to what I've mistakenly done. It is easy with some methods to throw away a return value without noticing.

If I am calling a method which has a return value I am ignoring, it might be nice if it made it a little more obvious I am doing so. Perhaps an underline with a note explaining that I am not processing a return value. Sure lots of people ignore return values all the time, but they really shouldn't be. The return value probably exists for a reason.

As an example assume you want to get a substring.

string myString = "LongStringWithTooMuchStuffSoItProbablyNeedsToBeCutDownToSize";
myString.Substring(5,10);
Console.WriteLine(myString);

Looking at that code it is pretty easy to miss the fact that I am not doing anything with the return value. Right now the value written to the console is "LongStringWithTooMuchStuffSoItProbablyNeedsToBeCutDownToSize". I am just ignoring the value that substring is returning. This means I am not actually doing anything. I am just printing out the original string. What I really should have written is this.

string myString = "LongStringWithTooMuchStuffSoItProbablyNeedsToBeCutDownToSize";
myString = myString.Substring(5,10);
Console.WriteLine(myString);

It wouldn't be that difficult for a program to detect unused return values. I am already informed when I don't use variables. Since plenty of plug-ins for visual studio already read method signatures, one of them could easily detect that I am ignoring the return value of that method. Ah the little things. Not too big a deal, but kind of annoying since I executed my program once and had to look to see why my code didn't work as expected.

Maybe some program does mention this already, or maybe there is some setting I need to enable to do this. Please let me know if you know of one.

Nested Using Statements

I think it is a great idea to always be reading code. You may learn more than you intend to sometimes. Read an article to learn one trick and you may learn a completely different one. Earlier today I was reading some code written by Steve Smith. He wrote an extension method for the System.Web.UI.Control class called RenderControl. I was just looking to see what he had written, and from this little snippet of code I learned a cool trick.

 

public static string RenderControl(this System.Web.UI.Control control)
{
    StringBuilder sb = new StringBuilder();
    using (StringWriter sw = new StringWriter(sb))
    using (HtmlTextWriter textWriter = new HtmlTextWriter(sw))
    {
        control.RenderControl(textWriter);
    }
    return sb.ToString();
}

In the past I would have nested my using statements like this.

public static string RenderControl(this System.Web.UI.Control control)
{
    StringBuilder sb = new StringBuilder();
    using (StringWriter sw = new StringWriter(sb))
    {
        using (HtmlTextWriter textWriter = new HtmlTextWriter(sw))
        {
            control.RenderControl(textWriter);
        }
    }
    return sb.ToString();
}
So now I can go ahead and save myself some curly braces and extra indentation.

I enjoy all the little things one can learn from reader the code others write.

Difference Between Value Types and Reference Types in C#

I recently wrote an article for C# beginners in which I explain the differences between value types and reference types in C#. It was published on ASP Alliance today. If you're new to C# or are even a little fuzzy on these concepts, I recommend you check it out. Please offer some feedback good or bad. I really do read and appreciate feedback I receive. I try to improve what I write based on what others tell me.

I've seen so many people run aground with errors stemming from misunderstandings about and just forgetting the importance of value and reference types.

Good day and happy programming!

Visual C# 2008 Keyboard Shortcut Reference

As I've said previously, I am working with developers who are just beginning to learn the tools of the trade. They have a long way to go working with plenty of applications. All people always have more they can learn, so I'll pass along a useful reference here. I found this great reference sheet from Microsoft that has a bunch of key-bindings for Visual C# 2008. It is a PDF poster you can use to reference different shortcuts available to you.

http://www.microsoft.com/downloads/details.aspx?familyid=e5f902a8-5bb5-4cc6-907e-472809749973&displaylang=en

Return Within a C# Using Statement

While writing some code earlier today I needed to return from within a using statement. Doing these sorts of things always makes me appreciate the using statement and how wonderful it really is, so I decided to write about it here. As many of you know the using statement in C# is a good tool for managing types which will be accessing unmanaged resources. Some examples of these are SqlConnections, FileReaders, and plenty of other similar types. The key to these is that they all implement the IDisposable interface. This means that they all need to be cleaned up carefully after using them.

The using statement is great because it guarantees that the declared object is disposed no matter how the execution completes. Whether you reach the end curly brace marking the end of the using statement, throw and exception, or return from a function, the using statement will call the dispose method and clean up the object.

This was important in my code because I was able to return directly from within the using statement without worrying about whether or not eh dispose method will fire. Whenever I use an object which accesses unmanaged resources I always always always put it in a using statement.

It is very important to use a using statement, because it will give you this guarantee that the object will be disposed of correctly. The object's scope will be for the extent of the using statement, and during the scope of the object it will be read-only if defined in the using statement. This is also very nice, because it will prevent this important object which manages the unmanaged from being modified or reassigned.

This is safe to do, because of how great the using statement is. No matter which return we hit we know the XmlReader will be disposed of correctly.

using (XmlReader reader = XmlReader.Create(xmlPath))
{
    // ... Do some work...
    if (someCase)
        return 0;
    // ... Do some work...
    if (someOtherCase)
        return 1;
}
return -1;

Happy coding. Enjoy this powerful tool.

Update: I've posted a follow up to this post with a code sample. It shows that you can return from inside of a using statement in C#.

Differences Between Structures and Classes in C#

Earlier today I was looking for a good reference outlining the differences between structs and classes in C#. I wanted a refresher on the subject, because I've been doing a reasonable amount of teaching lately. At Lake Quincy Media we have hired a couple of developers currently in school. In bringing them up to speed, I've been explaining a lot about programming languages, paradigms, etc. and it is nice to have good references to make sure that I am not passing along misinformation. In my quest to make sure that I'm remembering things correctly I found a great resource showing the differences between C# structs and classes. It is a very nice reference. I has links to different sections and code examples showing the differences it lists. I'll definitely be recommending that these guys take a look at this resource.

Note: In my opinion the best one thing to remember when thinking about structs and classes is that structs behave like value types and classes like reference types. If you know how to interact with each of those then you'll understand a lot of the differences right away.

Happy Programming Everyone!

C# Generics vs C++ Templates

I regularly meet with a group of my college friends with whom I studied Computer Science. While at a great local bar we have plenty of interesting computer-related conversations. A lot of .NET developers probably spend most of their time discussing technical topics with other .NET developers. Our conversations are much more interesting because everyone there works with different languages and different types of technology. It really adds a lot to our discussions. So as has happened a few times, I mentioned C# Generics. As usual it sparked a conversation about how C# Generics are not as good as C++ Templates. As usual I agree with them. (Yes, I really do like C++ templates better than I like Generics in C#)

So I searched on MSDN, because I wanted to see what Microsoft cites as the key differences between C++ templates and C# Generics. I found this article explaining the differences between C++ templates and C# Generics. OK, I agree these are some important differences. It says on there specifically that they were not even trying to have as much functionality as templates. It is good that they said that, because the list of "differences" could be renamed "reasons why templates are better".

The list of reasons cites a bunch of differences in how they are able to be used. I still want to know the differences in the implementation of them. For that big important difference they have it separated from the nice list. Its in the paragraph of description. They mention one HUGE difference. As they say, "C# generic type substitutions are performed at runtime and generic type information is thereby preserved for instantiated objects." So what is the big deal you might say. There are good things and bad things here for generics.

Since templates are compiled at runtime, the compiler will figure out every version of the template it needs and will create the code for them. This is great because it gives optimal performance. Sure there is a bit more code, but it is nice to not have to create these methods at runtime. With C# Generics, the required code is created at runtime. Ok so that sounds pretty bad. It isn't really as bad as it sounds. Generics are implemented smartly, and because of this it isn't much of a performance issue. So at runtime our code will be created to handle the different types our generic can handle. What if we're going to have a bunch of types? If they're all value types then you could have a problem. It will actually create a completely new implementation of your code for every value type you use for the generic. If you're using a reference type it uses some cool tricks to point to the correct type, so it only has to have one reference type implementation. This means you'll have the performance hit once when you first need the generic on a reference type. Then it is a minimal hit each other time you need it.

Yes, I was a C++ programmer before I learned C#. I hope you enjoyed this post. I appreciate comments. I really like the ones which add something to the post, so if you've got extra information to add I encourage you do so. If I've made any mistakes in this, please let me know.