C# equiv to VB IsNumeric ?

  • Thread starter Thread starter PeteZ
  • Start date Start date
Hi,

You can use Convert.ToInt32/64, Convert.ToDouble, etc.

The class when converting throws an exception if the parameter string is not in a value that can be converted to such the destination type.

It controls as well the ranges (allowed min and max values) and throws an overflow exception.

So this will work without exception:
Convert.ToInt32 ("-34234")

but the following will throw an exception:
Convert.ToInt32 ("-34234897254072502724525")
 
You can actually access all your familiar VB method referencing visual basic within your csharp project
at this time I am not at home, and cannot remember which reference has to be added to your solution in order to have access to the below namespaces

Just normally I do not use this, and instead do a try and catch, and try to convert the numbers using Int32.Parse()...et

Microsoft.VisualBasic.Information.IsNumeric(value)

-- Dan
 
Hi!,

I think I read somewhere that you shouldn't use exceptions for simple
testing like this - raising exceptions is expensive, so they should only be
used to detect exceptional occurrences.

Maybe somebody can confirm/deny this?


message Hi,

You can use Convert.ToInt32/64, Convert.ToDouble, etc.

The class when converting throws an exception if the parameter string is not
in a value that can be converted to such the destination type.

It controls as well the ranges (allowed min and max values) and throws an
overflow exception.

So this will work without exception:
Convert.ToInt32 ("-34234")

but the following will throw an exception:
Convert.ToInt32 ("-34234897254072502724525")
 
Try using Double.TryParse,
which returns true or false and **does not** throw an exception.
--Peter
 
Sheila Jones said:
I think I read somewhere that you shouldn't use exceptions for simple
testing like this - raising exceptions is expensive, so they should only be
used to detect exceptional occurrences.

Maybe somebody can confirm/deny this?
Click to expand...

Well, it's *relatively* expensive - iterating through each character to
check whether or not it's a digit is certainly cheaper, but unless
you're testing millions of them and expecting a large proportion to be
invalid, it's unlikely to make much performance difference.
 
If you write a function of your own, called IsNumeric, then according to the
..NET guidelines, it should only return true or false and catch any
exceptions that may ocurr, but it can't propagate any exceptions to the
concumer. So you get get either true or you get false but you'll never get
an exception. So you can handle the exception, just don't rely on it. Do
what you can to anticipate it before it happens and he'll be fine.


Thanks,
Shawn
 
I think a problem with this is that you will still get thrown in to the
debugger if you're debugging with the 'break into the debugger when an
exception is thrown' option switched on.

I'm still not really convinced about using exceptions as a way to control
ordinary program flow...


Shawn B. said:
If you write a function of your own, called IsNumeric, then according to the
.NET guidelines, it should only return true or false and catch any
exceptions that may ocurr, but it can't propagate any exceptions to the
concumer. So you get get either true or you get false but you'll never get
an exception. So you can handle the exception, just don't rely on it. Do
what you can to anticipate it before it happens and he'll be fine.


Thanks,
Shawn



only
Click to expand...
 
I wasn't arguing that exceptions should be used here as a way to control
program flow. Simply that if you create an IsNumeric function, according
the the MS docs on .NET guidelines and style, that the method should only
return true or false but it will never throw an exception. What this means,
is that if an exception ocurrs inside the IsNumeric, that it should be
caught and ultimately return false but the point is that you should code in
such a way to avoid that in the first place. However, the point is even
further that according to MS, it should never throw an exception to the code
consuming the IsXXXX function. It should always handle the exception and
return either true or false. In a way, this is a form of flow control, but
technically, it isn't flow control per se. Just that if an exception
ocurrs, it should catch it and then return false. That's all I was saying,
and what MS was saying.

Thanks,
Shawn


Sheila Jones said:
I think a problem with this is that you will still get thrown in to the
debugger if you're debugging with the 'break into the debugger when an
exception is thrown' option switched on.

I'm still not really convinced about using exceptions as a way to control
ordinary program flow...
Click to expand...
 
public static bool IsNumeric(object value)
{
try
{
double d = System.Double.Parse(value.ToString(),
System.Globalization.NumberStyles.Any);
return true;
}
catch (FormatException)
{
return false;
}
}
 
Back
Top