[Semi-OT] About Exception Handling

  • Thread starter Thread starter C# Learner
  • Start date Start date
C

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
 
C# Learner said:
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?
Click to expand...

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
 
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
 
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 said:
As Joe Mayo mentioned, exceptions aren't all that inefficient as long as
Click to expand...
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.
 
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.
 
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
 
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.
 
C# Learner said:
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
Click to expand...

Thanks for the replies.
 
Nick said:
Another solution would be to actually interrogate the underlying Stream
class when using the BinaryReader class:

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

That assumes that the BinaryReader doesn't do any caching - if it does,
the stream will reach the end before the BinaryReader does.
 
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.
 
Back
Top