Brendan Enrick

Daily Software Development

Try Writing Try Methods

When I say "Try Methods", I am of course referring to the common prefix "Try" on a method, which implies that the method is going to attempt to do what you're asking by using an output parameter for the operation and using the return value to indicate whether the attempt succeeded.

The common ones that people see in the .NET Framework are the TryParse methods, which attempt to parse something and if it can't be parse, they assign the default value to the output parameter and return false. If the succeed, the parsed value will be placed in the output parameter and the return value will be true. If the code failed, the convention is to use the type’s default value to assign to the output parameter. This lets you write code like this:

int someNumber;
int.TryParse(userInput, out someNumber);
// use the number entered or the default 0
int result = 1 + someNumber;


This is also great when you're going to be checking whether the method succeeded. In fact, you can use the try method directly in the if block, which usually makes things nice and clean. Here is an example of using them like that:

int someNumber;
if (int.TryParse(userInput, out someNumber))
    // Do something with someNumber
    // Invalid input: handle this case accordingly


Yes, you know all of this and have seen it before, however, are you writing these types of methods yourself or is your only experience with them the standard TryParse ones?

What I am trying to emphasize here is that you need to write your own Try methods in your code. You will thank yourself later.

Everyone can see the obvious benefit of not having to check for the default value to see if it the method worked. You also don't have to have ugly Try-Catch logic in your code. You get an if statement instead.

The real benefit of a writing a Try method has nothing to do with what I've already said. The most important benefit, in my opinion, is that you have a return value from it that isn't the value you are using for your logic. By having this return value for its success, you have to decide on how to handle the case where it failed.

There are important cases that might be forgotten, but having a return value means that I need to handle the return value. When I have it, I need to decide what to do with it. There may be a message I need to display to a user. There may be logging I need to do. I might be able to ignore that case. What is important, however, is that I thought about how to handle it. I had the chance to make sure that I handled the case correctly.

Create your own “Try” methods. I recommend looking into creating your own “TryParse”, “TryGet”, TryDelete”, and anything else that has a chance of failure that you may want to handle.

Parameter Order Should Be Consistent

I was looking at a piece of code recently and noticed that someone was checking for a null parameter and throwing an ArgumentException, so I figured since ArgumentNullException inherits from ArgumentException I would just replace it with the more specific exception. Little did I know that Microsoft has a wee little bit of a problem with consistency on these.

With ArgumentExceptions it is important to have a message as well as specify which parameter is causing the trouble, so there are 2 string parameters in the ArgumentException constructor. What you might not know if you haven't switched one to the other is that they changed the order of those parameters. What I mean is that you call them like this.

throw new ArgumentException("The Message", "paramName");
throw new ArgumentNullException("paramName", "The Message");
throw new ArgumentOutOfRangeException("paramName", "The Message");

How can they possibly switch those?!?! If I am not mistaken the lower two exceptions actually inherit from the first one, so it is quite surprising that the ordering was not maintained in the second two. I need to keep an eye out for other such inconsistencies while I am working. They obviously can't easily fix it now, because too much code depends on the current ordering. I try to maintain consistence parameter ordering, but I am also not working on a framework.

.NET 3.5 is Open Source

Some very surprising news has come from Scott Guthrie in a recent blog post he has made. Visual Studio 2008 and .NET 3.5 will be shipping with the source for the base class libraries. As with a lot of the recent technology coming from Microsoft, the source code is open and not hidden away.

In the past, tools like Reflector have allowed developers to see what is going on within those libraries. These tools will no longer be as necessary. This source code is being released under the Microsoft Reference License (MS-RL). It seems Microsoft has started a new trend for itself in releasing its source code.

Debugging will now become much much easier with this code being open source. In the past developers have not been able to step into any of the base class libraries. Now that the source is open for everyone to see, people are able to go in and step through this code. This should make debugging much easier and better.

I think this is great that Microsoft is releasing more source code to the general public.

Happy coding.