Help with Try/catch

  • Thread starter Thread starter Craig Lister
  • Start date Start date
C

Craig Lister

I am having unexpected results with a Try/Catch. The method simply
recieves a string, and sends it to a ComPort. I am testing the
scenario of a lost connection.

So, I call this method...

public string WriteData(string msg, bool requireReply)
{
_comPort.DiscardInBuffer();
_comPort.WriteLine(msg);

if (requireReply)
{
try
{
return _comPort.ReadLine();
}
catch (TimeoutException toe)
{
throw;
}
}
return string.Empty;
}

My calling code is surrounded by a Try/Catch(TimeoutException toe).
However, when I run this code... the application breaks out and shows
me that the was an unhandled timeout exception.

What am I doing wrong? I excpect it to throw it to the calling code,
and handle it there.
 
I am having unexpected results with a Try/Catch. The method simply
recieves a string, and sends it to a ComPort. I am testing the
scenario of a lost connection.

So, I call this method...

public string WriteData(string msg, bool requireReply)
{
_comPort.DiscardInBuffer();
_comPort.WriteLine(msg);

if (requireReply)
{
try
{
return _comPort.ReadLine();
}
catch (TimeoutException toe)
{
throw;
}
}
return string.Empty;
}

My calling code is surrounded by a Try/Catch(TimeoutException toe).
However, when I run this code... the application breaks out and shows
me that the was an unhandled timeout exception.

What am I doing wrong? I excpect it to throw it to the calling code,
and handle it there.
Click to expand...

I suspect there is something in the code you are not showing that
has an effect.

using System;

namespace E
{
public class Demo
{
public string WriteData(string msg, bool requireReply)
{
//_comPort.DiscardInBuffer();
//_comPort.WriteLine(msg);

if (requireReply)
{
try
{
//return _comPort.ReadLine();
throw new TimeoutException();
}
catch (TimeoutException toe)
{
Console.WriteLine("Got you");
throw;
}
}
return string.Empty;
}

public static void Main(string[] args)
{
try
{
Demo o = new Demo();
o.WriteData("bla bla", true);
}
catch(TimeoutException toe)
{
Console.WriteLine("Got you again");
}
Console.ReadKey();
}
}
}

prints:

Got you
Got you again

here !

Arne
 
Thanks Arne.

I had indeed made a fool of myself. The try/catch was fine... but I
was testing the wrong calling methgod, which had no try/catch! :)

Thanks.
 
Craig said:
Thanks Arne.

I had indeed made a fool of myself. The try/catch was fine... but I
was testing the wrong calling methgod, which had no try/catch! :)
Click to expand...

Well--the try/catch in your original example isn't doing anything.

public string WriteData(string msg, bool requireReply)
{
_comPort.DiscardInBuffer();
_comPort.WriteLine(msg);

if (requireReply)
{
try
{
return _comPort.ReadLine();
}
catch (TimeoutException toe)
{
throw;
}
}
return string.Empty;
}
}

is the same as

public string WriteData(string msg, bool requireReply)
{
_comPort.DiscardInBuffer();
_comPort.WriteLine(msg);

if (requireReply)
{
return _comPort.ReadLine();
}
return string.Empty;
}
}

A try/catch that does nothing but rethrow the exception is the same as
not having the try/catch (other than the fact that when you are
debugging it gives you a place *within the method* where you can
position a breakpoint after an exception has occurred) and I think that,
unless the optimizer recognizes the situation and removes the exception
handling code, it's adding overhead to the process.
 
Well--the try/catch in your original example isn't doing anything.

public string WriteData(string msg, bool requireReply)
{
_comPort.DiscardInBuffer();
_comPort.WriteLine(msg);

if (requireReply)
{
try
{
return _comPort.ReadLine();
}
catch (TimeoutException toe)
{
throw;
}
}
return string.Empty;
}
}

is the same as

public string WriteData(string msg, bool requireReply)
{
_comPort.DiscardInBuffer();
_comPort.WriteLine(msg);

if (requireReply)
{
return _comPort.ReadLine();
}
return string.Empty;
}
}

A try/catch that does nothing but rethrow the exception is the same as
not having the try/catch (other than the fact that when you are
debugging it gives you a place *within the method* where you can
position a breakpoint after an exception has occurred) and I think that,
unless the optimizer recognizes the situation and removes the exception
handling code, it's adding overhead to the process.
Click to expand...

Yes.

I would say **** the performance penalty.

But it also makes the code less readable and may cause
maintenance programmers to spend time wondering what the
purpose is.

Arne
 
Back
Top