In .NET 1.1, TryParse is only available for the Double datatype. Version 2.0 of the framework extends TryParse to all the basic datatypes. Why do we care? Performance. Parse throws an exception if the conversion from a string to the specified datatype fails, whereas TryParse explicitly avoids throwing an exception.
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2005/08/tryparse-and-the-exception-tax.html
You can use TryParse for any numbers in .NET 1.1. You just need to pass the appropriate arguments, then check the output is within MinValue and MaxValue of, say, Int32. Seems to work for me anyway, and I expect it’s faster than using a Regex, though I haven’t tested this.
There’s a new article on CodeProject showing the performance implications of exceptions in a variety of contexts:
Converting 1000 strings with success rate of 75, as your example:
Datatype Parse TryParse
Int32 2222 ms 0ms
Decimal 2147 ms 0ms
Double 3251 ms 0ms
DateTime 2354 ms 3ms
.NET 2.0 beta 2, Athlon 1800+
Ok so maybe I should run without debugging
Datatype Parse TryParse
Int32 23 ms 0ms
Decimal 24 ms 0ms
Double 37 ms 0ms
DateTime 29 ms 4ms
Yes, I agree it’s always better to have the knowledge to make a call one way or another, rather than go by a checklist of NEVER do this, or ALWAYS do this.
Knowledge is power
I thought you might have written your own blogging software Jeff.
I would think it would only take one dedicated day to replicate the features I can see here.
Although of course, I can’t see the back-end administration interface, which is where most the complication typically is.
this is useful to know. Was converting a VB.NET app and it had a bunch of IsDate, IsNumeric function invokations that I wanted to replace with .NET equivalents, and could not find any easy and simple solutions.
Using a regex to check for valid numbers isn’t failsafe at all. Did you consider things like locale-specific syntax (France uses a comma for decimal places, not a dot) and minimum and maximum possible values (I bet a string of a million 8s will pass your regex but fail to convert to a valid number)?
There have been some optimizations, but the difference is still there. Change the “success rate” to something below 100 percent to see it.
Nice article. But is there a performance penalty of including an Exception, if you know the exception is never bound to be hit.
I downloaded and ran the example in VS 2005 and the times on both parse and TryParse are identical.
I am running a HP laptop from 2006 1.6GHZ with 2 Megs of RAM. AMD Atalon 64. So me, sticking with TryParse. I need the exception handler.
One of the first things that our company always puts into our base project is a Utility class that has static methods like IsInteger and IsNumeric(allows decimals). This is very easy to accomplish with regex, and is a great deal cheaper than exceptions.
There’s no excuse to do a blind Parse call without validating the input string first. This can be more difficult with using DateTimes due to the wide variety of ways that a date can be input, so I always avoid that by using a third-party calendar control, or by using drop-down lists.
This would be good functionality to throw into the .NET framework. Either the methods could be tied to the System.String class, or each of the respective types(Int32, Int64, Double, etc.).
Interestingly enough I just posted a similar topic (though not as in depth) here: http://jaysonknight.com/blog/archive/2005/08/10/1736.aspx
I was going back thru the archives and re-read this post. Just for kicks I downloaded the project and ran it under Visual Studio 2008, still targeting the 2.0 Framework. The weird thing was, that the times for parse and tryparse came out the same, both under release and debug.
Now my question is, what is causing this behavior? Pretty sure it isn’t my dual-core processor, as the app isn’t multithreaded. Has Microsoft been back-optimizing the performance of the Framework?