Try/Catch is a last resort to things that can’t be handled with normal code. IE, connections and timeouts or other such critical errors.

If you need to use exception handling to try and convert a String into an Int then your being lazy in your validation code.

I can generate reports on the out come of TryParse without needing the Try/Catch exception handling.

Try/Catch is expensive in resources and should only be used sparingly. Not a replacement to proper validation code.

double.TryParse(”34.12345″, out doubleVar)

it seems that doubleVar becomes equal to 34.1234 instead of 34.12345. It seems as though TryParse (and probably Parse for that matter) cuts off some decimal places even though the type has plenty of space to hold them. This is a frustrating problem that seems like either a bug or a very bad design decision. Does anyone have any ideas on how to get TryParse to parse the string containing a number to as many decimal places as the string originally contains (and obviously as many as the type will allow)?

Thanks for the article Mark.

I thought that the link at the bottom of my article, then one that says “Benchmark Test”, kind of gave an impression of how well it performs?

anyway, if I was biased about the example then I would probably have added one more Catch to it ;P

I know that it might look like overkill and that you probably just as easily could use Exception. However, my rule of thumb is that you should only catch specific exceptions

http://fatagnus.com/back-to-basic-with-the-try-catch-statement/

The example is very simple, but it displays the usage of the function. It doesn’t fit into every single context of how one would use it :)

best regards
Mark

int quantity;
try
{
quantity = txtQuantity.Text;
}
catch (Exception Ex)
{
quantity = 0;
}

That is the revised code of your 1st example and actually same as how the 2nd example works. Now this is a fairer comparision and i will see that 2nd example isn’t that miraclous. Maybe the OUT overload’s just synatic sugar, as i am unsure of the difference in performance. Maybe you can go further and demostrate the difference in performance.

i agree with mark.
If I saw this during a review, i’d change it.

the original example is pretty close to best practice.
use TryParse in an ‘if’ statement…if the Parse fails you can return the default, set it to a known error value, i.e. -1, or throw an exception.

someone made the point about catching exceptions, and they’re correct.
this gives you control over the exception under this particular circumstance and can aid you considerably later