What is better: int.TryParse or try { int.Parse() } catch

I know.. I know... Performance is not the main concern here, but just for curiosity, what is better?

bool parsed = int.TryParse(string, out num);
if (parsed)
...

OR

try {
    int.Parse(string);
}
catch () {
    do something...
}

Better is highly subjective. For instance, I personally prefer int.TryParse, since I most often don't care why the parsing fails, if it fails. However, int.Parse can (according to the documentation) throw three different exceptions:

• the input is null
• the input is not in a valid format
• the input contains a number that produces an overflow

If you care about why it fails, then int.Parse is clearly the better choice.

As always, context is king.

Is it exceptional for the conversion to sometimes fail, or is it expected and normal that the conversion will sometimes fail? If the former, use an exception. If the latter, avoid exceptions. Exceptions are called "exceptions" for a reason; you should only use them to handle exceptional circumstances.

If it is indeed expected that the conversion will sometimes fail, I like to use int.TryParse and such neatly on one line with the conditional (Ternary) operator, like this:

int myInt = int.TryParse(myString, out myInt) ? myInt : 0;

In this case zero will be used as a default value if the TryParse method fails.

Also really useful for nullable types, which will overwrite any default value with null if the conversion fails.

The first. The second is considered coding by exception.

Personally, I'd prefer:

if (int.TryParse(string, out num))
{
   ...
} 

The first! You should not code by exception.

you could shorten it to

if (int.TryParse(string, out num))

First, by far. As George said, second is coding by exception and has major performance impacts. And performance should be a concern, always.

Catching an Exception has more overhead, so I'll go for TryParse.

Plus, TryParse method does not throw an exception if the conversion fails. It eliminates the need to use exception handling to test for a FormatException in the event that s is invalid and cannot be successfully parsed.

That last part copy-pasted from here

Something else to keep in mind is that exceptions are logged (optionally) in the Visual Studio debug/output window. Even when the performance overhead of exceptions might be insignificant, writing a line of text for each exception when debugging can slow things right down. More noteworthy exceptions might be drowned amongst all the noise of failed integer parsing operations, too.