views:

246

answers:

4

What are the pros and cons of using either of the following approaches to pulling out a double from an object? Beyond just personal preferences, issues I'm looking for feedback on include ease of debugging, performance, maintainability etc.

public static double GetDouble(object input, double defaultVal)
{
    try
    {
        return Convert.ToDouble(input);
     }
     catch
     {
        return defaultVal;
     }
}

public static double GetDouble(object input, double defaultVal)
{
    double returnVal;
    if (double.TryParse(input.ToString(), out returnVal))
    {
        return returnVal;
    }
else
    {
        return defaultVal;
    }
}
+2  A: 

TryParse is more efficient than TryCatch performance wise.

Sunil
+12  A: 
  • TryParse will be faster than catching an exception
  • TryParse indicates something expected - nothing exceptional is happening here, it's just that you suspect your data may not be valid.
  • TryParse isn't using exception handling for normal control flow

Basically, go with TryParse :)

By the way, your code can be rewritten as:

public static double GetDouble(object input, double defaultVal)
{
    double parsed;
    return double.TryParse(input.ToString(), out parsed)) ? parsed : defaultVal;
}
Jon Skeet
GM Jon,What is the internal implementation of tryparse() ? Is it like this:try{Parse();return true;}catch(Exception){return false;}
Sunil
TryParse casts to String (actually a char*), tries to parse that string to a Number (via character comparisons), then does various other checks (range etc.) to ensure the Number is the correct type. There's not a try catch block around it :)
Ed Woodcock
+2  A: 

Having the Parse methods throw exceptions on bad input was a design flaw. Bad input is expected behavior when you take in data from a user. Exception throwing is expensive, it's not something you want happening routinely in your code.

Thankfully, Microsoft realized their mistake and added the TryParse methods. TryParse does not incur the overhead of exception throwing on bad input, but the downside is it has to return two pieces of data, so it feels a bit awkward to use.

Now if they hadn't created the broken Parse implemetation in the first place, TryParse would just be called Parse.

John Knoeller
+1  A: 

TryParse is faster and usually better but I would suggest the TryCatch approach in framework and back-end programming because you can give more information to the client about the error:

public double GetAge()
{
   try
   {
      var input = _dataProvider.GetInput();
      return Convert.ToDouble(input);
   }
   catch(Exception ex)
   {
      throw new MyBackendException(ex);
   }
}
onof
You could still use TryParse and raise your own exception on bad data. In fact, you should do it that way, for tracing purposes if nothing else.
Chris Charabaruk
Ok, but you would have only a generic message about "bad data" and you will loose the information about why data is bad. Information that is in an InvalidCastException or a FormatException or . Programming on a given framework I would like as much as possible info about an error.Anyway, when bad data could come from a web service or from storage it's not a "expected behavior" and IMO exception must be thrown.
onof