Is There a Way to Avoid This Mess?

  • Thread starter Thread starter C# Learner
  • Start date Start date
C

C# Learner

Is there a way to avoid the following mess?

int i = 0;
if (someString != null) {
try {
i = Int32.Parse(someString);
} catch (FormatException) {

}
}

More specifically, is there a way of avoiding the ugly empty catch
statement?
 
Yes, put the mess in a function somewhere.

public int ToInt32(object value)
{
try
{
return Convert.ToInt32(value);
}
catch { }
}
 
Michael said:
Yes, put the mess in a function somewhere.

public int ToInt32(object value)
{
try
{
return Convert.ToInt32(value);
}
catch { }
}
Click to expand...

Isn't that a nasty "hack" though? Surely there's a better way?!
 
Not Really,
It is no different than if you tried to use Integer.ParseInt(string) in
java.

I dont remember off hand how it is done in c++ but it might be similar.
I know there is no implicit conversion so it is probably sitting in string.h
somewhere ctoi probably

Dave
 
If you are gone do anything with the exception, then just don't catch it, I mean..


public int ToInt32(object value

return Convert.ToInt32(value)
 
Hector said:
If you are gone do anything with the exception, then just don't catch it, I mean...


public int ToInt32(object value)
{
return Convert.ToInt32(value);
}
Click to expand...

But I *need* to catch the exception, or else it'll bubble up and
eventually cause an exception dialog to show.
 
Dave said:
Not Really,
It is no different than if you tried to use Integer.ParseInt(string) in
java.

I dont remember off hand how it is done in c++ but it might be similar.
I know there is no implicit conversion so it is probably sitting in string.h
somewhere ctoi probably
Click to expand...

It's atoi() in ANSI C. On success, it returns the converted integer.
On failure, it returns 0. This would be ideal here!
 
C# Learner wrote:

<snip>

Well, I guess I'll have to write my own (efficient one) that returns a
default value passed to it on error.

..NET let me down *again*.

Thanks for the replies.
 
Rick said:
Yeah, but that's not what you want now is it? At least not in most cases. 0
is a valid value that an int can hold. This is hardly a solution.

+++ Rick ---
Click to expand...

It would be ideal _here_, but I can definitely see your point with
regards to /general/ usage.

Better would be something like:

int n = ToInt32Def(someString, 0); // 0 is the value to return on error

or perhaps:

bool succeded = TryToInt32(somestring, out n);
 
it's a not a good idea to write your OWN one,

and it'll not be a efficient one,

and anyway you should process the exception.

so write a warpper

public int ToInt32(object value){...}

is THE soluton.
 
You need TryParse -- it attempts the parse, and returns true/false on
success/failure. Problem is that it *only* is available for the double type --
don't ask me why, more .NET shortsightedness...

So, you could do the following:

double result = 0;
int i = double.TryParse(someString, style*, provider*, result) ? (int)result :
0;

A *little* cleaner.

*Define style and provider to your specific needs
 
C# Learner said:
C# Learner wrote:

<snip>

Well, I guess I'll have to write my own (efficient one) that returns a
default value passed to it on error.

.NET let me down *again*.
Click to expand...

I don't see why this is such a let down for you. Yes, you have to write
a method which is all of about 8 lines long. Why is that such a
problem? You shouldn't expect .NET to provide you absolutely everything
gift-wrapped: you should expect it to provide you enough tools so that
you can reasonably easily get the effect you want, just as you can
here.
 
Jon said:
I don't see why this is such a let down for you. Yes, you have to write
a method which is all of about 8 lines long. Why is that such a
problem? You shouldn't expect .NET to provide you absolutely everything
gift-wrapped: you should expect it to provide you enough tools so that
you can reasonably easily get the effect you want, just as you can
here.
Click to expand...

That's the /thing/ about .NET - it can be _very_ useful in some
respects, but in others, it *just* cuts short of the mark. In these
other cases, that fact is a slight annoyance.

An analogy: it's the dream house you've just bought, which initially
appears flawless. But then, one day, while standing in one of the
rooms, the floorboards break through due to lack of strength, and down
you fall. You then need to build a wrapper around this faulty
floorboard, and wonder for how many other floorboards you'll need to do
this.

To be honest, I wouldn't ever complain about .NET if I didn't think it
could handle it.
 
Julie said:
You need TryParse -- it attempts the parse, and returns true/false on
success/failure. Problem is that it *only* is available for the double type --
don't ask me why, more .NET shortsightedness...

So, you could do the following:

double result = 0;
int i = double.TryParse(someString, style*, provider*, result) ? (int)result :
0;

A *little* cleaner.

*Define style and provider to your specific needs
Click to expand...

Thanks.
 
C# Learner said:
That's the /thing/ about .NET - it can be _very_ useful in some
respects, but in others, it *just* cuts short of the mark. In these
other cases, that fact is a slight annoyance.

An analogy: it's the dream house you've just bought, which initially
appears flawless. But then, one day, while standing in one of the
rooms, the floorboards break through due to lack of strength, and down
you fall. You then need to build a wrapper around this faulty
floorboard, and wonder for how many other floorboards you'll need to do
this.
Click to expand...

The problem with this analogy is that you don't know when the
floorboards are going to break. In the .NET case, it's not like it
fails in an unpredictable way (at least, not in the example you've
given). You don't need to worry about *every* floorboard being faulty -
you just need to write a few lines of code because .NET happens not to
supply the precise behaviour you want all wrapped up in one method
call.

Personally I don't see that as a problem at all.
 
Try double.TryParse, which returns true or false, and does not throw an
exception.
--Peter
 
The real problem with this issue is the lack of consistency.

The double type has a TryParse, none of the other numeric types do. Why not?
 
Julie J. said:
The real problem with this issue is the lack of consistency.

The double type has a TryParse, none of the other numeric types do. Why not?
Click to expand...

That I don't know. It would be okay if a double could accurately
represent any other data type, but it clearly can't represent all longs
or decimals. (I think it's okay with all of the other types.)
 
Jon said:
That I don't know. It would be okay if a double could accurately
represent any other data type, but it clearly can't represent all longs
or decimals. (I think it's okay with all of the other types.)
Click to expand...

Hmm... I wonder if they would ever consider resolving* this apparent
inconsistency in the future.

* [by adding TryParse() to all relevant types]
 
Back
Top