My application reads an Excel file using VSTO and adds the read data to a StringDictionary
. It adds only data that are numbers with a few digits (1000 1000,2 10
I generally try to avoid the Convert
class (meaning: I don't use it) because I find it very confusing: the code gives too few hints on what exactly happens here since Convert
allows a lot of semantically very different conversions to occur with the same code. This makes it hard to control for the programmer what exactly is happening.
My advice, therefore, is never to use this class. It's not really necessary either (except for binary formatting of a number, because the normal ToString
method of number classes doesn't offer an appropriate method to do this).
To start with, I'd use double.Parse
rather than Convert.ToDouble
in the first place.
As to whether you should use Parse
or TryParse
: can you proceed if there's bad input data, or is that a really exceptional condition? If it's exceptional, use Parse
and let it blow up if the input is bad. If it's expected and can be cleanly handled, use TryParse
.
Double.TryParse IMO.
It is easier for you to handle, You'll know exactly where the error occurred.
Then you can deal with it how you see fit if it returns false (i.e could not convert).
Lots of hate for the Convert class here... Just to balance a little bit, there is one advantage for Convert - if you are handed an object,
Convert.ToDouble(o);
can just return the value easily if o is already a Double (or an int or anything readily castable).
Using Double.Parse or Double.TryParse is great if you already have it in a string, but
Double.Parse(o.ToString());
has to go make the string to be parsed first and depending on your input that could be more expensive.
Personally, I find the TryParse
method easier to read, which one you'll actually want to use depends on your use-case: if errors can be handled locally you are expecting errors and a bool from TryParse
is good, else you might want to just let the exceptions fly.
I would expect the TryParse
to be faster too, since it avoids the overhead of exception handling. But use a benchmark tool, like Jon Skeet's MiniBench to compare the various possibilities.
This is an interesting old question. I'm adding an answer because nobody noticed a couple of things with the original question.
Which is faster: Convert.ToDouble or Double.TryParse? Which is safer: Convert.ToDouble or Double.TryParse?
I'm going to answer both these questions (I'll update the answer later), in detail, but first:
For safety, the thing every programmer missed in this question is the line (emphasis mine):
It adds only data that are numbers with a few digits (1000 1000,2 1000,34 - comma is a delimiter in Russian standards).
Followed by this code example:
Convert.ToDouble(regionData, CultureInfo.CurrentCulture);
What's interesting here is that if the spreadsheets are in Russian number format but Excel has not correctly typed the cell fields, what is the correct interpretation of the values coming in from Excel?
Here is another interesting thing about the two examples, regarding speed:
catch (InvalidCastException)
{
// is not a number
}
This is likely going to generate MSIL that looks like this:
catch [mscorlib]System.InvalidCastException
{
IL_0023: stloc.0
IL_0024: nop
IL_0025: ldloc.0
IL_0026: nop
IL_002b: nop
IL_002c: nop
IL_002d: leave.s IL_002f
} // end handler
IL_002f: nop
IL_0030: return
In this sense, we can probably compare the total number of MSIL instructions carried out by each program - more on that later as I update this post.
I believe code should be Correct, Clear, and Fast... In that order!