By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,383 Members | 2,070 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,383 IT Pros & Developers. It's quick & easy.

[Semi-OT] About Exception Handling

P: n/a
Some time ago, I remember reading a discussion about the strengths and
weaknesses of exception handling. One of the weaknesses that was put
forward was that exception handling is inefficient (in the way of CPU
usage), compared to the "normal" practise returning values.

How true is this? Will using using exception handling, in general, be
much less efficient than returning values, or less efficient at all?

Just curious...

TIA
Nov 15 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
"C# Learner" <cs****@learner.here> wrote in message
news:go********************************@4ax.com...
Some time ago, I remember reading a discussion about the strengths and
weaknesses of exception handling. One of the weaknesses that was put
forward was that exception handling is inefficient (in the way of CPU
usage), compared to the "normal" practise returning values.

How true is this? Will using using exception handling, in general, be
much less efficient than returning values, or less efficient at all?


Hi C# Learner,

In C#, exception handling doesn't cost you anything until an exception is
actually raised. While there is a performance hit, it is generally not
significant enough to care about and the benefits outweigh the drawbacks of
the old method of returning error values.

When you use exception handling, you gain a lot more information about what
is happening in your application. Just think about the basic Exception
object, there is a message, StackTrace, and other properties that give you a
lot of insight into what happened when the exception was raised.
Additionally, you can define your own custom exceptions when one of the many
exceptions that ship with the BCL doesn't meet your needs. When an
exception is raised, you can't ignore or forget about it because it is in
your face. You also have much more flexibility in how you handle
exceptions, as opposed to results from a method, with stack unwinding,
unhandled exception handlers, and cool stuff like that.

Joe
--
http://www.csharp-station.com

Nov 15 '05 #2

P: n/a
As Joe Mayo mentioned, exceptions aren't all that inefficient as long as no exceptions are actually thrown. However, you should assume that throwing exceptions is very expensive. Essentially, you should never use exceptions for normal control flow. Throw exceptions only in truly exceptional cases -- cases that should rarely or never come up in actual program runs. If you're throwing and catching exceptions often, it's not only bad style, but can also be a pretty severe performance hit

-- Ada

----- C# Learner wrote: ----

Some time ago, I remember reading a discussion about the strengths an
weaknesses of exception handling. One of the weaknesses that was pu
forward was that exception handling is inefficient (in the way of CP
usage), compared to the "normal" practise returning values

How true is this? Will using using exception handling, in general, b
much less efficient than returning values, or less efficient at all

Just curious..

TI

Nov 15 '05 #3

P: n/a
I agree with your point to avoid exceptions for normal control flow but it
seems like there's no other way to handle some things in .Net

Example :
How do you detect the end of stream of a BinaryReader? There might be a
better way but that's the most efficient one I found for now.

=========== start code ===========
BinaryReader br = new BinaryReader(File.OpenRead(@"c:\test.txt"));

while (true)
{
try
{
byte current = br.ReadByte();
}
catch (EndOfStreamException e)
{
// The end of the stream was detected, time to get out of the loop
break;
}
}
=========== end code ===========

Yves

"AdamMil" <an*******@discussions.microsoft.com> schreef in bericht
news:35**********************************@microsof t.com...
As Joe Mayo mentioned, exceptions aren't all that inefficient as long as no exceptions are actually thrown. However, you should assume that throwing
exceptions is very expensive. Essentially, you should never use exceptions
for normal control flow. Throw exceptions only in truly exceptional cases --
cases that should rarely or never come up in actual program runs. If you're
throwing and catching exceptions often, it's not only bad style, but can
also be a pretty severe performance hit.
-- Adam

----- C# Learner wrote: -----

Some time ago, I remember reading a discussion about the strengths and weaknesses of exception handling. One of the weaknesses that was put
forward was that exception handling is inefficient (in the way of CPU
usage), compared to the "normal" practise returning values.

How true is this? Will using using exception handling, in general, be much less efficient than returning values, or less efficient at all?

Just curious...

TIA

Nov 15 '05 #4

P: n/a
The best way to detect an end of stream is to use ReadBytes. It returns with a
read result of 0 if 0 bytes
are read and hence 0 bytes are available and the stream is at an end. You also
have PeekChar which returns
-1 if no more data is available on the stream. I would recommend against using
exceptions to control your
program flow, especially in the case of files where other methods exist.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"phoenix" <pa******@skynetWORK.be> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
I agree with your point to avoid exceptions for normal control flow but it
seems like there's no other way to handle some things in .Net

Example :
How do you detect the end of stream of a BinaryReader? There might be a
better way but that's the most efficient one I found for now.

=========== start code ===========
BinaryReader br = new BinaryReader(File.OpenRead(@"c:\test.txt"));

while (true)
{
try
{
byte current = br.ReadByte();
}
catch (EndOfStreamException e)
{
// The end of the stream was detected, time to get out of the loop
break;
}
}
=========== end code ===========

Yves

"AdamMil" <an*******@discussions.microsoft.com> schreef in bericht
news:35**********************************@microsof t.com...
As Joe Mayo mentioned, exceptions aren't all that inefficient as long as

no exceptions are actually thrown. However, you should assume that throwing
exceptions is very expensive. Essentially, you should never use exceptions
for normal control flow. Throw exceptions only in truly exceptional cases --
cases that should rarely or never come up in actual program runs. If you're
throwing and catching exceptions often, it's not only bad style, but can
also be a pretty severe performance hit.

-- Adam

----- C# Learner wrote: -----

Some time ago, I remember reading a discussion about the strengths

and
weaknesses of exception handling. One of the weaknesses that was put
forward was that exception handling is inefficient (in the way of CPU
usage), compared to the "normal" practise returning values.

How true is this? Will using using exception handling, in general,

be
much less efficient than returning values, or less efficient at all?

Just curious...

TIA


Nov 15 '05 #5

P: n/a
I'm working with bytes not chars. When I use PeekChar I always get
"conversion buffer overflow" as error. What I really would need is PeekByte
which isn't available though (which I find pretty odd since it is a
BinairyReader after all). PeekChar would mean more exception handling in
stead of less.
Using ReadBytes forces me to use an array (of length 1 ...) which I didn't
want.

The best solution I could come up with was not using the BinaryReader but
using the Stream class. Then I could use Stream.ReadByte of which I could
use the return value to detect EOF (-1).

I wonder though what the difference in cost/performance is between doing the
check each time you read a byte or just catching that 1 exception.

Yves

"Justin Rogers" <Ju****@games4dotnet.com> schreef in bericht
news:u7**************@TK2MSFTNGP11.phx.gbl...
The best way to detect an end of stream is to use ReadBytes. It returns with a read result of 0 if 0 bytes
are read and hence 0 bytes are available and the stream is at an end. You also have PeekChar which returns
-1 if no more data is available on the stream. I would recommend against using exceptions to control your
program flow, especially in the case of files where other methods exist.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"phoenix" <pa******@skynetWORK.be> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
I agree with your point to avoid exceptions for normal control flow but it seems like there's no other way to handle some things in .Net

Example :
How do you detect the end of stream of a BinaryReader? There might be a
better way but that's the most efficient one I found for now.

=========== start code ===========
BinaryReader br = new BinaryReader(File.OpenRead(@"c:\test.txt"));

while (true)
{
try
{
byte current = br.ReadByte();
}
catch (EndOfStreamException e)
{
// The end of the stream was detected, time to get out of the loop
break;
}
}
=========== end code ===========

Yves

"AdamMil" <an*******@discussions.microsoft.com> schreef in bericht
news:35**********************************@microsof t.com...
As Joe Mayo mentioned, exceptions aren't all that inefficient as long as
no exceptions are actually thrown. However, you should assume that throwing exceptions is very expensive. Essentially, you should never use exceptions for normal control flow. Throw exceptions only in truly exceptional cases -- cases that should rarely or never come up in actual program runs. If you're throwing and catching exceptions often, it's not only bad style, but can
also be a pretty severe performance hit.

-- Adam

----- C# Learner wrote: -----

Some time ago, I remember reading a discussion about the
strengths and
weaknesses of exception handling. One of the weaknesses that was
put forward was that exception handling is inefficient (in the way of CPU usage), compared to the "normal" practise returning values.

How true is this? Will using using exception handling, in general, be
much less efficient than returning values, or less efficient at

all?
Just curious...

TIA



Nov 15 '05 #6

P: n/a
Another solution would be to actually interrogate the underlying Stream
class when using the BinaryReader class:

while NotEOF(br)
{
byte current = br.ReadByte();
....
}

private bool NotEOF(BinaryReader br)
{
return br.Stream.Position < br.Stream.Length;
}

I havent compiled this, but the concept is correct.

Nick.
"phoenix" <pa******@skynetWORK.be> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
I'm working with bytes not chars. When I use PeekChar I always get
"conversion buffer overflow" as error. What I really would need is PeekByte which isn't available though (which I find pretty odd since it is a
BinairyReader after all). PeekChar would mean more exception handling in
stead of less.
Using ReadBytes forces me to use an array (of length 1 ...) which I didn't
want.

The best solution I could come up with was not using the BinaryReader but
using the Stream class. Then I could use Stream.ReadByte of which I could
use the return value to detect EOF (-1).

I wonder though what the difference in cost/performance is between doing the check each time you read a byte or just catching that 1 exception.

Yves

"Justin Rogers" <Ju****@games4dotnet.com> schreef in bericht
news:u7**************@TK2MSFTNGP11.phx.gbl...
The best way to detect an end of stream is to use ReadBytes. It returns with a
read result of 0 if 0 bytes
are read and hence 0 bytes are available and the stream is at an end. You also
have PeekChar which returns
-1 if no more data is available on the stream. I would recommend
against using
exceptions to control your
program flow, especially in the case of files where other methods exist.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

"phoenix" <pa******@skynetWORK.be> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
I agree with your point to avoid exceptions for normal control flow but
it seems like there's no other way to handle some things in .Net

Example :
How do you detect the end of stream of a BinaryReader? There might be
a better way but that's the most efficient one I found for now.

=========== start code ===========
BinaryReader br = new BinaryReader(File.OpenRead(@"c:\test.txt"));

while (true)
{
try
{
byte current = br.ReadByte();
}
catch (EndOfStreamException e)
{
// The end of the stream was detected, time to get out of the loop
break;
}
}
=========== end code ===========

Yves

"AdamMil" <an*******@discussions.microsoft.com> schreef in bericht
news:35**********************************@microsof t.com...
> As Joe Mayo mentioned, exceptions aren't all that inefficient as long
as no exceptions are actually thrown. However, you should assume that throwing exceptions is very expensive. Essentially, you should never use exceptions for normal control flow. Throw exceptions only in truly exceptional cases -- cases that should rarely or never come up in actual program runs. If you're throwing and catching exceptions often, it's not only bad style, but
can also be a pretty severe performance hit.
>
> -- Adam
>
> ----- C# Learner wrote: -----
>
> Some time ago, I remember reading a discussion about the
strengths and
> weaknesses of exception handling. One of the weaknesses that
was put > forward was that exception handling is inefficient (in the way
of
CPU > usage), compared to the "normal" practise returning values.
>
> How true is this? Will using using exception handling, in general, be
> much less efficient than returning values, or less efficient at all? >
> Just curious...
>
> TIA
>



Nov 15 '05 #7

P: n/a
C# Learner <cs****@learner.here> wrote:
Some time ago, I remember reading a discussion about the strengths and
weaknesses of exception handling. One of the weaknesses that was put
forward was that exception handling is inefficient (in the way of CPU
usage), compared to the "normal" practise returning values.

How true is this? Will using using exception handling, in general, be
much less efficient than returning values, or less efficient at all?

Just curious...

TIA


Thanks for the replies.
Nov 15 '05 #8

P: n/a
Nick <fr**@here.com> wrote:
Another solution would be to actually interrogate the underlying Stream
class when using the BinaryReader class:

while NotEOF(br)
{
byte current = br.ReadByte();
....
}


That assumes that the BinaryReader doesn't do any caching - if it does,
the stream will reach the end before the BinaryReader does.

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

P: n/a
Thats a really good point Jon. From the codelet provided by Yves, no
non-default configurables for the classes used were defined. It seems the
BinaryReader is badly designed, as its PeekChar clearly fails when
processing binary data, and exceptions are used for normal control flow (if
I am reading through a file, I expect to get to the end at some point). If
I was dealing with this problem, I would simply use the stream direct:

Stream sr = File.OpenRead(@"c:\test.txt");
int current;
while ((current = sr.ReadByte()) != -1)
{
Console.Write((char)current);
}
Console.ReadLine();
Nick.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Nick <fr**@here.com> wrote:
Another solution would be to actually interrogate the underlying Stream
class when using the BinaryReader class:

while NotEOF(br)
{
byte current = br.ReadByte();
....
}


That assumes that the BinaryReader doesn't do any caching - if it does,
the stream will reach the end before the BinaryReader does.

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

Nov 15 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.