try-catches

[Tim923]

Are try-catches mainly just used for code that could generate a
run-time error like division-by-zero, or the letter "A" for an
integer.

Someone said we could use try-catch in a situation, but since no
possible run-time error was involved, I used if-else statements
instead.

-
http://mysite.verizon.net/vze8adrh/news.html (profile) --Tim923 My email is valid.

[Manish.net]

Hi Tim,

Yes Try Catch are mailly used for code that probably can generate some
exception and we can catch that exception and can take appropriate action, so
that application will not crash or behave unexpectedly.

Some times user throws his custom exceptions for some conditions in
application.

Manish
"Tim923" wrote:

Are try-catches mainly just used for code that could generate a
run-time error like division-by-zero, or the letter "A" for an
integer.

Someone said we could use try-catch in a situation, but since no
possible run-time error was involved, I used if-else statements
instead.

-
http://mysite.verizon.net/vze8adrh/news.html (profile) --Tim923 My email is valid.

[Michael Culley]

"Tim923" <ju********@verizon.net> wrote in message
news:0u********************************@4ax.com...

Are try-catches mainly just used for code that could generate a
run-time error like division-by-zero, or the letter "A" for an
integer.

Someone said we could use try-catch in a situation, but since no
possible run-time error was involved, I used if-else statements
instead.

It's probably better to avoid using try catch if possible because an
exception is fairly resource intensive.

Michael Culley

[W.G. Ryan eMVP]

Try/catches are used to handle situations that you expect could happen but
can't necessarily avoid. If you try to open a db connection, the server may
be down - so you may want to catch it and write the stuff to a queue so you
can get it later. However you shouldn't use try/catching in place of
checking for preconditions appropriately. Catching exceptions isn't cheap
so if you can use an IF statement to avoid them, by all means do it.

Jon Skeet has an excellent analysis of this on his site...let me see if I
can find the link.

--
W.G. Ryan MVP (Windows Embedded)

TiBA Solutions
www.tibasolutions.com | www.devbuzz.com | www.knowdotnet.com
"Tim923" <ju********@verizon.net> wrote in message
news:0u********************************@4ax.com...

Are try-catches mainly just used for code that could generate a
run-time error like division-by-zero, or the letter "A" for an
integer.

Someone said we could use try-catch in a situation, but since no
possible run-time error was involved, I used if-else statements
instead.

-
http://mysite.verizon.net/vze8adrh/news.html (profile) --Tim923 My email

is valid.

[Jon Skeet [C# MVP]]

Michael Culley <mc*****@NOSPAMoptushome.com.au> wrote:

Are try-catches mainly just used for code that could generate a
run-time error like division-by-zero, or the letter "A" for an
integer.

Someone said we could use try-catch in a situation, but since no
possible run-time error was involved, I used if-else statements
instead.

It's probably better to avoid using try catch if possible because an
exception is fairly resource intensive.

No it's not. Not if it's thrown reasonably infrequently. Exceptions
seem to be given an incredibly bad press for no particularly good
reason these days. While I certainly wouldn't recommend throwing them
within a tight loop, or indeed throwing them at all for a non-
exceptional condition, they're perfectly reasonable to throw for
genuine error situations where the method can't fulfil its contract.
They're a far safer way of indicating this than return codes.

In terms of performance, my laptop can throw 100,000 exceptions in a
second. I've seen people who haven't done such a test tell others that
throwing 2000 exceptions in an *hour* is probably harming their
performance significantly, which is rubbish. There are reasons for not
throwing 2000 exceptions in an hour, but performance isn't one of them.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

W.G. Ryan eMVP <Wi*********@NoSpam.gmail.com> wrote:

Try/catches are used to handle situations that you expect could happen but
can't necessarily avoid. If you try to open a db connection, the server may
be down - so you may want to catch it and write the stuff to a queue so you
can get it later. However you shouldn't use try/catching in place of
checking for preconditions appropriately. Catching exceptions isn't cheap
so if you can use an IF statement to avoid them, by all means do it.

Jon Skeet has an excellent analysis of this on his site...let me see if I
can find the link.

Do I? I'm not sure I have :)

I suspect you're referring to the test I did for finding a quick way of
parsing possibly-dodgy numbers.

Have a search for a thread entitled "Checking if a string can be
converted to Int32" on groups.google.com, in the
microsoft.public.dotnet.framework group.

Throwing an exception is certainly more expensive than not throwing an
exception - but if thrown at a reasonable frequency (which should be
low for reasons more important than performance) the performance
penalty should get lost in the noise.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Michael Culley]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

No it's not. Not if it's thrown reasonably infrequently.
So what you're really saying is that they are resourse intensive otherwise
you wouldn't have added the "reasonably infrequently". This function below
is around 3000 times slower without the first line. Of course you shouldn't
go out of your way to avoid exceptions but if it's reasonable to avoid them
like in the code below you may as well.

int ToInt32(object value)
{
if(value == DBNull.Value) return 0;
try
{
return Convert.ToInt32(value);
}
catch
{
return 0;
}
}
In terms of performance, my laptop can throw 100,000 exceptions in a
second. I've seen people who haven't done such a test tell others that
throwing 2000 exceptions in an *hour* is probably harming their
performance significantly, which is rubbish. There are reasons for not
throwing 2000 exceptions in an hour, but performance isn't one of them.

Damn you must have a *really* fast laptop. My p4 2.4 desktop couldn't get
anywhere near that. :-)

Michael

[Jon Skeet [C# MVP]]

Michael Culley <mc*****@NOSPAMoptushome.com.au> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

No it's not. Not if it's thrown reasonably infrequently.
So what you're really saying is that they are resourse intensive
otherwise you wouldn't have added the "reasonably infrequently". This
function below is around 3000 times slower without the first line.

Only if you feed it DBNull all the time though, presumably... What
happens if you only feed it DBNull once in a million times, as might
reasonably the case in some applications? In that case, it could well
be *slower* to avoid the non-occurring exception in the common case
than the cost of the exception in the rare case.
Of course you shouldn't go out of your way to avoid exceptions
But there are times where it's possible to avoid it, but that *does*
involve going out of your way. On such occasions, I'd usually go with
the simpler code, unless I had any reason to believe it would be a
significant performance problem. For instance, I've shown elsewhere
that if you've got a lot of dodgy string data which is going to be
converted to ints, it's much faster to do a hard-coded check
beforehand. However, if I'm reasonably expecting the data to be
correct, I could avoid a *possible* exception by using that check, but
I wouldn't bother, because it would make the code more complicated for
very little (if any) performance gain.
but if it's reasonable to avoid them like in the code below
you may as well.

int ToInt32(object value)
{
if(value == DBNull.Value) return 0;
try
{
return Convert.ToInt32(value);
}
catch
{
return 0;
}
}

Yes, where possible it's worth avoiding them, but as much for stylistic
reasons as performance ones. If you end up getting to the situation
where you're throwing enough exceptions that it becomes a bottleneck in
your code, there's probably more wrong than just performance.

In terms of performance, my laptop can throw 100,000 exceptions in a
second. I've seen people who haven't done such a test tell others that
throwing 2000 exceptions in an *hour* is probably harming their
performance significantly, which is rubbish. There are reasons for not
throwing 2000 exceptions in an hour, but performance isn't one of them.

Damn you must have a *really* fast laptop. My p4 2.4 desktop couldn't get
anywhere near that. :-)

It's a P4 3.06GHz.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Michael Culley]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Only if you feed it DBNull all the time though, presumably... What
happens if you only feed it DBNull once in a million times, as might
reasonably the case in some applications? In that case, it could well
be *slower* to avoid the non-occurring exception in the common case
than the cost of the exception in the rare case.
It is just an example to show that in some cases exceptions are very
resource intensive. Compared to what you would expect an exception is very
slow. I agree this has probably been exaggerated a lot causing people to go
out of their way to avoid them.
But there are times where it's possible to avoid it, but that *does*
involve going out of your way. On such occasions, I'd usually go with
the simpler code, unless I had any reason to believe it would be a
significant performance problem. For instance, I've shown elsewhere
that if you've got a lot of dodgy string data which is going to be
converted to ints, it's much faster to do a hard-coded check
beforehand. However, if I'm reasonably expecting the data to be
correct, I could avoid a *possible* exception by using that check, but
I wouldn't bother, because it would make the code more complicated for
very little (if any) performance gain.

Quite possibly, that's something you have to consider for each situation.

Michael

[Jeff Louie]

Tim.... It is appropriate to throw an exception if the caller violates
the explicit
preconditions of the method, if the method is unable to maintain an
invariant,
or if the method cannot meet the stated postconditions.

http://www.geocities.com/jeff_louie/OOP/oop14.htm

Regards,
Jeff

Someone said we could use try-catch in a situation, but since no

possible run-time error was involved, I used if-else statements
instead.<
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!