Convert to TryParse

Introduction

Consider that you are assigned to a project to create a very cool application which captures the name, age and date of birth of the user and saves all the data to the database. Yay!

So you go ahead and design a cool form, complete with two text boxes to capture the name & age and add a date picker control to select the date of birth. Sweet!

Now comes the tough part - saving the values to the database. The DBAs really out-did themselves on this one and designed a table which could hold all this information like so:

CREATE TABLE Users
(Name VARCHAR(50), Age INT(3), DateOfBirth DATETIME)

Oh, the wicked people! You quake in fear, since your controls expose only a text property and return the values as text. Surely the DBAs could have designed with this in mind. But they work in a different world that you don't quite understand (or control) and so grudgingly, you look at what you could do to convert your string values to the types the table expects.

After burning the midnight oil, you come up with a solution like so:

private void saveUser()
{
    try{

        string name = txtName.Text;
        int age = Convert.ToInt32(txtAge.Text);
        DateTime dateOfBirth = Convert.ToDateTime(txtDateTime.Text);

        // Code to save to the database

    }
    catch(System.Exception ex){
        // Code to do something with the error
    }
}

Nice, so you managed to convert the values to the types needed by the database and you threw in the try-catch block to handle anything going wrong in your code. You think you are almost done so you call in the new fresh-out-of-college-dude who joined your team last week to show off your master-piece. One look and he has the nerve to mention Validation controls on the client-side so that you would save the server round-trip if the data is invalid.

You throw him a few dagger looks and put in some Validator controls so that the data can be validated on the client. You can hear the drums beating, the bugles sounding as you push out your code to your manager for some review and feedback while you head out for a celebration. Surely, he would be impressed.

The next day, your inbox has a single line cryptic mail from your manager: "Doesn't work, JS disabled." Now you have two headaches - the hangover and the mail. You need to act on them, fast!

So you make your way out to your geek friend who happens to be good at fixing code issues. "Dude" you say, "could you please look into this code, I think I did not handle the OnServerValidate event of the Validation controls". While he peers at your code, you take a walk to find something for that hangover.

By the time you are back, your geek God has changed your code like so:

private void saveUser()
{
    try{
        string name; int age; DateTime dateOfBirth;

        if(!String.IsNullOrEmpty(txtName.Text) 
            && int.TryParse(txtAge.Text, out age) 
            && DateTime.TryParse(txtDateOfBirth.Text, out dateOfBirth))
        {
            // Code to save to the database
        }
        else
        {
            // Show validation error
        }
    }
    catch(System.Exception ex){
        // Code to do something with the error
    }
}

You groan out load! You had asked him to handle the OnServerValidate event for each control and he just wrote a few lines of code which you do not understand, you can feel your headache starting up again. You want to ask him about it, but have a reputation to protect. Besides, you could always look it up on Google to know what it is and if there is any performance benefit in doing this.

So, you decide to let the code remain as is - if it is good enough for the geek, it should be good enough for your manager. So you fire off an answering mail to your manager with an equally cryptic: "Please review & comment" and get out of the office - time to hit the sack.

When you get to work the third day, the first thing you notice is that the fresh-out-of-college-dude is now a fresh-out-of-college-dude-with-wide-eyes, the second thing you notice is there is no mail in your inbox from your manager (no news, is good news) and finally it dawns on you that your application has shipped bug free - touch wood.

A new project? Bring it on, you say, life is good.

History

• 17^th June, 2008: Initial post