[MichaelGG]

TryParse returns a boolean. So you use it like this:

  int res;
  if int.TryParse(s, out res) { // OK } { else // not ok }

You certainly do not need an exception to deal with the simple case of "did this string parse into an int".

Edit: A great alternative signature is to use Maybe/Option, so you get Some int or None.

  match int.TryParse s with
  | None   -> ...
  | Some i -> ...

[DoubleMalt]

Ah apparently I remembered it wrong. I thought it was

int res = int.TryParse(s, 0); // 0 as the default if parsing fails

Of course if there is no reasonable default you should bubble the thing up anyway or handle it on the spot. But very often for input parsing there is sane default you can choose.

[lucastheisen]

is that really more work than:

  int res;
  try { res = Integer.parseInt( s ); } // if part
  catch ( NumberFormatException nfe ) { } // else part

The words are different (try/catch instead of if/else), but still 2 blocks of code with similar syntax...

[MichaelGG]

The main reason for TryParse, AFAIK, is avoiding the massive expense of exceptions on the CLR.

Another reason is composability. If you're checking several values together, returning a Maybe/Option is much more clear and usable.