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
SoftCircuits Programming
http://www.softcircuits.com

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

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

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
}


On Wed, 14 Feb 2007 06:36:12 +0100, Jonathan Wood <(E-Mail Removed)>
wrote:

> 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.
>



--
Happy Coding!
Morten Wennevik [C# MVP]

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.

"Jonathan Wood" <(E-Mail Removed)> wrote in message
news:%233z9ip$(E-Mail Removed)...
>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
> 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




On Feb 13, 9:36 pm, "Jonathan Wood" <j...@softcircuits.com> wrote:
> 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
> SoftCircuits Programminghttp://www.softcircuits.com

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

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>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
>
>
>
>
> On Feb 13, 9:36 pm, "Jonathan Wood" <j...@softcircuits.com> wrote:
>> 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
>> SoftCircuits Programminghttp://www.softcircuits.com
>
>

Paul Hadfield <(E-Mail Removed)> wrote:
> 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...

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

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

And I'll use TryParse().

Thanks.

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

"Morten Wennevik [C# MVP]" <(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
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
}


On Wed, 14 Feb 2007 06:36:12 +0100, Jonathan Wood <(E-Mail Removed)>
wrote:

> 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.
>



--
Happy Coding!
Morten Wennevik [C# MVP]

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

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>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
>
>
>
>
> On Feb 13, 9:36 pm, "Jonathan Wood" <j...@softcircuits.com> wrote:
>> 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
>> SoftCircuits Programminghttp://www.softcircuits.com
>
>

Jonathan Wood <(E-Mail Removed)> wrote:
> 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.

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too