Avoiding Exceptions

[Jonathan Wood]

I must be the only one who doesn't think exceptions are the greatest thing
since bread.

Consider the following code:

id = Convert.ToInt32(Request.QueryString["id"]);

First, is there an easy way to tell which methods or properties could
potentially throw an exception? I've scanned the docs and it doesn't seem to
say. Without that knowledge, it's a bit of hit and miss.

Second, knowing that ToInt32() can throw an exception, is there any way to
prevent that? The line above already appears within a try...catch. However,
I don't want the same catch handler to handle problems with this line. I'd
like it handled differently. What other choice is there besides creating an
additional try and/or catch block? And doesn't that seem like overkill?

Thanks.

 

[Mattias Sjögren]

Jonathan,

Second, knowing that ToInt32() can throw an exception, is there any way to
prevent that?

If you're targeting .NET 2.0, consider using Int32.TryParse instead of
Convert.ToInt32.


Mattias

 

[Morten Wennevik [C# MVP]]

Hi Jonathan,

The documentation say what kind of exceptions they might throw. Depending
on what data type you pass to Convert.ToInt32 you might get an
OverflowException, InvalidCastException, ArgumentException or
FormatException, although to know this you have to read the documentation
on every overloaded method. Knowing that Request.QueryString[string] will
return a string narrows it down to a FormatException or OverflowException

For primitive data types there is also a TryParse method that will not
throw an exception, but return true or false to indicate if the parse was
successfull.

int id = 0;
if(!Int32.TryParse(Request.QueryString["id"], out id))
{
// not a valid integer
}

I must be the only one who doesn't think exceptions are the greatest
thing
since bread.

Consider the following code:

id = Convert.ToInt32(Request.QueryString["id"]);

First, is there an easy way to tell which methods or properties could
potentially throw an exception? I've scanned the docs and it doesn't
seem to
say. Without that knowledge, it's a bit of hit and miss.

Second, knowing that ToInt32() can throw an exception, is there any way
to
prevent that? The line above already appears within a try...catch.
However,
I don't want the same catch handler to handle problems with this line.
I'd
like it handled differently. What other choice is there besides creating
an
additional try and/or catch block? And doesn't that seem like overkill?

Thanks.

 

[Paul Hadfield]

Before Int.TryParse() in 2.0, I did something like below:

public static class FailSafeConvert
{
public static int ConvertToInt( object value, int defaultValue)
{
try
{
Convert.ToInt32(value);
}
catch
{
return defaultValue;
}
}
}

I don't have the coder to hand, if Convert.ToInt32 doesn't take an Object,
then I know I had a similar method ConvertToString() which I may have
wrapped the value up in first.

Regards,

- Paul.

 

[pfc_sadr]

I would reccomend doing something like this your structured error
handling is a bunch of crap; and I've always preferred the classic way
to implement error handling

can't Csharp do this?

ROFL

Public Function MyFunction(strIn as string) as string
on error goto errhandler

MyFunction = "Hello World " & strIn

cleanExit:
exit sub
errHandler:
msgbox err.number & " - " & err.description, vbokonly
resume next
End Function

 

[Paul Hadfield]

Time to call it a day and go home I think - I nearly missed the sarcasm!

I would reccomend doing something like this your structured error
handling is a bunch of crap; and I've always preferred the classic way
to implement error handling

can't Csharp do this?

ROFL

Public Function MyFunction(strIn as string) as string
on error goto errhandler

MyFunction = "Hello World " & strIn

cleanExit:
exit sub
errHandler:
msgbox err.number & " - " & err.description, vbokonly
resume next
End Function

I must be the only one who doesn't think exceptions are the greatest
thing
since bread.

Consider the following code:

id = Convert.ToInt32(Request.QueryString["id"]);

First, is there an easy way to tell which methods or properties could
potentially throw an exception? I've scanned the docs and it doesn't seem
to
say. Without that knowledge, it's a bit of hit and miss.

Second, knowing that ToInt32() can throw an exception, is there any way
to
prevent that? The line above already appears within a try...catch.
However,
I don't want the same catch handler to handle problems with this line.
I'd
like it handled differently. What other choice is there besides creating
an
additional try and/or catch block? And doesn't that seem like overkill?

Thanks.

 

[Jon Skeet [C# MVP]]

Time to call it a day and go home I think - I nearly missed the sarcasm!

I don't think there was any sarcasm involved - see the rest of
pfc_sadr's posts. He's basically trolling...

 

[Jonathan Wood]

Okay, I do see ToInt32() has an Exception section.

And I'll use TryParse().

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

Hi Jonathan,

The documentation say what kind of exceptions they might throw. Depending
on what data type you pass to Convert.ToInt32 you might get an
OverflowException, InvalidCastException, ArgumentException or
FormatException, although to know this you have to read the documentation
on every overloaded method. Knowing that Request.QueryString[string] will
return a string narrows it down to a FormatException or OverflowException

For primitive data types there is also a TryParse method that will not
throw an exception, but return true or false to indicate if the parse was
successfull.

int id = 0;
if(!Int32.TryParse(Request.QueryString["id"], out id))
{
// not a valid integer
}

I must be the only one who doesn't think exceptions are the greatest
thing
since bread.

Consider the following code:

id = Convert.ToInt32(Request.QueryString["id"]);

First, is there an easy way to tell which methods or properties could
potentially throw an exception? I've scanned the docs and it doesn't seem
to
say. Without that knowledge, it's a bit of hit and miss.

Second, knowing that ToInt32() can throw an exception, is there any way
to
prevent that? The line above already appears within a try...catch.
However,
I don't want the same catch handler to handle problems with this line.
I'd
like it handled differently. What other choice is there besides creating
an
additional try and/or catch block? And doesn't that seem like overkill?

Thanks.

 

[Jonathan Wood]

AFAIC, that VB approach is no different from structured exception handling.
I wasn't crazy about that either.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

I would reccomend doing something like this your structured error
handling is a bunch of crap; and I've always preferred the classic way
to implement error handling

can't Csharp do this?

ROFL

Public Function MyFunction(strIn as string) as string
on error goto errhandler

MyFunction = "Hello World " & strIn

cleanExit:
exit sub
errHandler:
msgbox err.number & " - " & err.description, vbokonly
resume next
End Function

I must be the only one who doesn't think exceptions are the greatest
thing
since bread.

Consider the following code:

id = Convert.ToInt32(Request.QueryString["id"]);

First, is there an easy way to tell which methods or properties could
potentially throw an exception? I've scanned the docs and it doesn't seem
to
say. Without that knowledge, it's a bit of hit and miss.

Second, knowing that ToInt32() can throw an exception, is there any way
to
prevent that? The line above already appears within a try...catch.
However,
I don't want the same catch handler to handle problems with this line.
I'd
like it handled differently. What other choice is there besides creating
an
additional try and/or catch block? And doesn't that seem like overkill?

Thanks.

 

[Jon Skeet [C# MVP]]

AFAIC, that VB approach is no different from structured exception handling.
I wasn't crazy about that either.

So what's your preferred way of handling errors? Every method returning
a value to say whether or not it's succeeded, and using out parameters
for what would otherwise be return values? (i.e. the old C way of doing
things.)

I've seen how badly that worked out - I'm much happier with exceptions,
by and large.

 

[Jonathan Wood]

Jon,

So what's your preferred way of handling errors? Every method returning
a value to say whether or not it's succeeded, and using out parameters
for what would otherwise be return values? (i.e. the old C way of doing
things.)

In some cases, structured exception handling is nice. In particular, in
cases where no error is expected yet many are possible.

But in other cases, such as verifying user input, testing a return value is
far more efficient.

I've seen how badly that worked out - I'm much happier with exceptions,
by and large.

It worked for me; however, as long as it's easy to see which exceptions each
method might raise, and I'm able to find methods such as TryParse() when I
need verify input, then I don't have an issue with it.

 

[Jon Skeet [C# MVP]]

In some cases, structured exception handling is nice. In particular, in
cases where no error is expected yet many are possible.

But in other cases, such as verifying user input, testing a return value is
far more efficient.

Which is why TryParse exists. FWIW, I believe the number of places
where exceptions may be thrown but you can usually keep going is
*vastly* lower than the number of places where an exception means "I
want to get way up the stack really quickly and abort the whole large
operation". It's *much* easier to get that right with exceptions than
return codes.

It worked for me; however, as long as it's easy to see which exceptions each
method might raise, and I'm able to find methods such as TryParse() when I
need verify input, then I don't have an issue with it.

Goodo. Java tries to raise awareness of exceptions which might be
thrown by having the concept of "checked exceptions" - if you call a
method which declares that it throws a checked exception, you've either
got to catch that exception yourself, or declare that your method might
throw the checked exception too.

Unfortunately it doesn't work very well in the long run - more and more
Java frameworks are now moving to unchecked exceptions instead.

I'm sure there's a better way yet to be invented, but I'm glad that I
don't have to make every method call part of an "if" statement...