tags:

views:

108

answers:

4
string s1 = "1234"; 
string s2 = "1234.65"; 
string s3 = null; 
string s4 = "123456789123456789123456789123456789123456789";  

result = Int32.Parse(s1); //-- 1234
result = Int32.Parse(s2); //-- FormatException 
result = Int32.Parse(s3); //-- ArgumentNullException 
result = Int32.Parse(s4); //-- OverflowException 

result = Convert.ToInt32(s1); //-- 1234 
result = Convert.ToInt32(s2); //-- FormatException 
result = Convert.ToInt32(s3); //-- 0 
result = Convert.ToInt32(s4); //-- OverflowException 

success = Int32.TryParse(s1, out result); //-- success => true; result => 1234 
success = Int32.TryParse(s2, out result); //-- success => false; result => 0 
success = Int32.TryParse(s3, out result); //-- success => false; result => 0 
success = Int32.TryParse(s4, out result); //-- success => false; result => 0 

From this link

Why do we need these many conversion functions when the intent of the operation is to just convert a string to int.

I am sorry if my question is stupid.

+1  A: 

There are performance trade off for each of those methods.

For instance TryParse will not throw an exception, so if you have to do a lot of converting rapidly you should use that method and then check for null, so you do go through the performance hit for instantiating an exception and catching it.

aceinthehole
+1  A: 

They are not all the same, they have slightly different behaviors.

For example - the TryParse pattern will not throw an exception if the format is incorrect, the Try will.

In regards to Convert vs Parse - convert will call Parse under the hoods, with the additional check for a passed in null (it will return a 0 if a null is passed in).

Oded
A: 

For Int32.Parse you just provided one of four overloads. This changes the perspective substationally.

Perhaps the Int32.Parse calls back on the Convert methods. But Convert is also a separate collection of simple parsing methods. Since the exceptions are the same, I guess it's likely it calls down on the Convert methods.

And as for the TryParse methods, I would hardly say they perform the same job!

Also see this link

Claus Jørgensen
+13  A: 

They do 3 different things:

Int32.Parse() expects a string which is an exact representation of an integer. It is extremely limited - it either parses a string or explodes.

Int32.TryParse() is the same as Parse, but has the extra overhead of performing validation. So in cases where you aren't sure if the incoming string is parseable, it's better than Parse and catching an exception (very expensive). But TryParse is wasteful in cases where you can be highly confident a simple Parse will do.

Convert.ToInt32 is the most complex - it actually determines if the incoming object is convertible, not parseable, to an int. It supports converting between many native (known) types, but also inspects the incoming object to see if the object provides its own logic via IConvertible essentially saying "yes, I can be converted to an integer - here's how".

Rex M
+1 Did not realize that difference with Convert
kekekela
Just for completeness, TryParse is a LOT faster than a try/catch around a Int32.Parse. If you're doing lots of parsing that may fail, using TryParse may give your app a big performance boost.
Eduardo Scoz
@Eduardo thanks, I reworded the answer to make that point very explicit instead of implied.
Rex M
@Rex M Thanks for such a neat answer. Then why did the expensive and unclear methods are not removed. We can just have only TryParse and force the users to use that. Is there any reason why such things are not enforced?
Sandeep
@Sandeep because Convert does a *lot* more than Parse. It's a matter of having different tools for different cases and knowing which one is best for a specific situation.
Rex M