[Semi-OT] About Exception Handling

[C# Learner]

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

[Joe Mayo]

"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

[AdamMil]

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

[phoenix]

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

[Justin Rogers]

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

[phoenix]

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

[Nick]

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
>

[C# Learner]

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.

[Jon Skeet [C# MVP]]

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

[Nick]

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