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

问题:

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

回答1:

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 procudes an overflow

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

As always, context is king.

回答2:

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.

回答3:

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.

回答4:

The first. The second is considered coding by exception.

回答5:

Personally, I'd prefer:

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

回答6:

The first! You should not code by exception.

you could shorten it to

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

回答7:

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

回答8:

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

回答9:

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.