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 1000,34 - comma is a delimiter in Russian standards).

What is better to check if the current string is an appropriate number?

FYI, double.TryParse is the same thing as try { result = double.Parse(s); return true; } catch { return false; }. Convert is essentially a wrapper for both with a bunch of overloads. It makes no difference how you do it. But as Jon has pointed out, think about how to handle bad input.
–
John LeidegrenFeb 25 '09 at 15:52

7

Double.TryParse isn't the same as double.Parse wrapped in a try..catch. The semantics are the same, but the code path is different. TryParse first verifies that the string is a number using an internal Number.TryStringToNumber, whereas Parse assumes it already is a number/double.
–
Jeff MoserFeb 25 '09 at 22:31

9 Answers
9

I did a quick non-scientific test in Release mode. I used two inputs: "2.34523" and "badinput" into both methods and iterated 1,000,000 times.

Valid input:
Double.TryParse = 646ms
Convert.ToDouble = 662 ms

Not much different, as expected. For all intents and purposes, for valid input, these are the same.

Invalid input:
Double.TryParse = 612ms
Convert.ToDouble = .. well.. it was running for a long time. I reran the entire thing using 1,000 iterations and Convert.ToDouble with bad input took 8.3 seconds. Averaging it out, it would take over 2 hours. O_o. I don't care how basic the test is, in the invalid input case, Convert.ToDouble's exception raising will ruin your performance.

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.

Jon,Can you elaborate on why you prefer double.Parse over Convert.ToDouble?
–
David NorthApr 8 '11 at 16:28

4

@dnorthut: I rarely want null to be converted to 0 (which Convert.ToDouble does), basically. It's also generally more flexible. I just tend to go for the specific methods...
–
Jon SkeetApr 8 '11 at 16:52

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).

Unless you are 100% certain of your inputs, which is rarely the case, you should use Double.TryParse.

Convert.ToDouble will throw an exception on non-numbers
Double.Parse will throw an exception on non-numbers or null
Double.TryParse will return false or 0 on any of the above without generating an exception.

The speed of the parse becomes secondary when you throw an exception because there is not much slower than an exception.

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.