3

Hi I found this function in a utilities code file:

Version 1:

public static bool IsValidLong(string strLong)
{
    bool result = true;
    try
    {
        long tmp = long.Parse(strLong);
    }
    catch (Exception ex)
    {
        result = false;
    }
    return result;
}

I want to replace this (and validators for other types) with following:

Version 2:

public static bool IsValidLong(string strLong)
{
    long l;
    return long.TryParse(strLong, out l);
}

which version is better and why?

TheVillageIdiot
  • 40,053
  • 20
  • 133
  • 188

4 Answers4

3

The first exists because the 2nd didn't at one point (Int64.TryParse() was added in .Net 2.0)...use the second version, why not take advantage of the features the framework adds in the newer releases if they're available to you? :)

The second is much clearer, leaner and more maintinable...I'd say it's a much better approach... it just wasn't available before.

Also, I believe TryParse() doesn't actually throw any exception internally, so it would be slower in a successful parse, but much quicker/less expensive than throwing an exception in the case of a failed parse.

Nick Craver
  • 623,446
  • 136
  • 1,297
  • 1,155
  • thanks @Nick I don't thing the code is that old. It was written not before .Net 2.0 – TheVillageIdiot May 29 '10 at 10:57
  • @TheVillageIdiot - It's likely the programmer just didn't know about `.TryParse()` at the time then. – Nick Craver May 29 '10 at 10:58
  • 1
    Why would `TryParse` be slower? In fact, that is not the case; for a successful parse both are equally fast. See http://stackoverflow.com/questions/2922565/which-one-is-faster-in-processing-and-conversion-int-parse-int-tryparse-con/2922629#2922629 and http://blogs.msdn.com/b/ianhu/archive/2005/12/19/505702.aspx. When it comes to performance it is usually better not to believe as it is so easy to be wrong... ;-) But it is correct that `TryParse` does not throw exceptions internally so that it will be significantly faster on erroneous input. – Dirk Vollmar May 29 '10 at 12:22
  • @0xA3: There is some overhead to TryParse for that exception-less handling, you can run a simple loop to test this. I ran 10,000,000 iterations of TryParse vs Parse in a simple linqpad test here, TryPrase: **1249-1280ms** over 10 tests, Parse: **1143-1152ms** over the same 10 tests. Try it yourself: http://pastebin.com/AUQ6RpF8 – Nick Craver May 29 '10 at 12:34
  • When I ran you sample I didn't see a significant difference. One possible explanation could be that LinqPad doesn't optimize the code as well as the C#/JIT compilers do. – Dirk Vollmar May 29 '10 at 20:01
1

I prefer the second one since both do same and second one is less code.

Inv3r53
  • 2,929
  • 3
  • 25
  • 37
1

In the second version the FW is encapsulating the behaviour in the first version for you. I would say that the two examples are equivalent but I would say the code in the second example is cleaner.

Robben_Ford_Fan_boy
  • 8,494
  • 11
  • 64
  • 85
0

version 2 is better, wrap code in a try/catch block will affect performance, I think the TryParse() implementation will not use this approach.

glenngao
  • 115
  • 2
  • 6