471,582 Members | 1,429 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,582 software developers and data experts.

Exception Handling - .Net Runtime Error Unhandled Exceptions

I have built an asychronous TCP Server that uses the thread pool. I have two
levels of exception handling in case the handling of the inner catch block
throws an exception. The outer catch block does nothing put print a string
literal to our logging mechanism. The general structure for this is:

AsyncReceiveCallback
{
try
{
OnReceiveDelegate();
}
catch (SocketException)
{
...
}
catch (ObjectDisposedException)
{
...
}
catch (Exception ex)
{
...
}
}
catch (Exception ex)
{
...
}
}

The OnReceiveDelegate is what handles the application business logic and
this business logic also has exception handling, but in some cases it may not
catch everything. My question here is shouldn't my exception handling in the
AsyncReceiveCallback method catch any unhandled exception returning from the
OnReceiveDelegate method?

Aug 31 '06 #1
3 3068
Note: I accidentally left out the top try:

AsyncReceiveCallback
{
try
{
try
{
OnReceiveDelegate();
}
catch (SocketException)
{
...
}
catch (ObjectDisposedException)
{
...
}
catch (Exception ex)
{
...
}
}
catch (Exception ex)
{
...
}
}
"Larry Herbinaux" wrote:
I have built an asychronous TCP Server that uses the thread pool. I have two
levels of exception handling in case the handling of the inner catch block
throws an exception. The outer catch block does nothing put print a string
literal to our logging mechanism. The general structure for this is:

AsyncReceiveCallback
{
try
{
OnReceiveDelegate();
}
catch (SocketException)
{
...
}
catch (ObjectDisposedException)
{
...
}
catch (Exception ex)
{
...
}
}
catch (Exception ex)
{
...
}
}

The OnReceiveDelegate is what handles the application business logic and
this business logic also has exception handling, but in some cases it may not
catch everything. My question here is shouldn't my exception handling in the
AsyncReceiveCallback method catch any unhandled exception returning from the
OnReceiveDelegate method?
Aug 31 '06 #2
Larry,

Yes. It should catch any exception thrown by OnReceiveDelegate. In
fact, it should catch any exceptions thrown by the catch blocks of the
inner try-catch block as well. The only way AsyncReceiveCallback can
throw an exception is if the outer catch block generates it. Are you
observing different behavior?

Brian

Larry Herbinaux wrote:
Note: I accidentally left out the top try:

AsyncReceiveCallback
{
try
{
try
{
OnReceiveDelegate();
}
catch (SocketException)
{
...
}
catch (ObjectDisposedException)
{
...
}
catch (Exception ex)
{
...
}
}
catch (Exception ex)
{
...
}
}
"Larry Herbinaux" wrote:
I have built an asychronous TCP Server that uses the thread pool. I have two
levels of exception handling in case the handling of the inner catch block
throws an exception. The outer catch block does nothing put print a string
literal to our logging mechanism. The general structure for this is:

AsyncReceiveCallback
{
try
{
OnReceiveDelegate();
}
catch (SocketException)
{
...
}
catch (ObjectDisposedException)
{
...
}
catch (Exception ex)
{
...
}
}
catch (Exception ex)
{
...
}
}

The OnReceiveDelegate is what handles the application business logic and
this business logic also has exception handling, but in some cases it may not
catch everything. My question here is shouldn't my exception handling in the
AsyncReceiveCallback method catch any unhandled exception returning from the
OnReceiveDelegate method?
Sep 1 '06 #3
Brian,

Yes we are having some exceptions that cause a .Net Runtime error. We have
at least one general business logic exception that we are looking into, but
we also see it in our production environment when we switch from one DB
Cluster Node to another (not all the time...but this could be to timing
issues...e.g. in the middle of a SQL Request or not when switch occurs).

"Brian Gideon" wrote:
Larry,

Yes. It should catch any exception thrown by OnReceiveDelegate. In
fact, it should catch any exceptions thrown by the catch blocks of the
inner try-catch block as well. The only way AsyncReceiveCallback can
throw an exception is if the outer catch block generates it. Are you
observing different behavior?

Brian

Larry Herbinaux wrote:
Note: I accidentally left out the top try:

AsyncReceiveCallback
{
try
{
try
{
OnReceiveDelegate();
}
catch (SocketException)
{
...
}
catch (ObjectDisposedException)
{
...
}
catch (Exception ex)
{
...
}
}
catch (Exception ex)
{
...
}
}
"Larry Herbinaux" wrote:
I have built an asychronous TCP Server that uses the thread pool. I have two
levels of exception handling in case the handling of the inner catch block
throws an exception. The outer catch block does nothing put print a string
literal to our logging mechanism. The general structure for this is:
>
AsyncReceiveCallback
{
try
{
OnReceiveDelegate();
}
catch (SocketException)
{
...
}
catch (ObjectDisposedException)
{
...
}
catch (Exception ex)
{
...
}
}
catch (Exception ex)
{
...
}
}
>
The OnReceiveDelegate is what handles the application business logic and
this business logic also has exception handling, but in some cases it may not
catch everything. My question here is shouldn't my exception handling in the
AsyncReceiveCallback method catch any unhandled exception returning from the
OnReceiveDelegate method?
>

Sep 4 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

44 posts views Thread by craig | last post: by
6 posts views Thread by Nick Reeves | last post: by
4 posts views Thread by Frank | last post: by
2 posts views Thread by Nak | last post: by
16 posts views Thread by Chuck Cobb | last post: by
6 posts views Thread by Phillip Taylor | last post: by
6 posts views Thread by Steve | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by lumer26 | last post: by
1 post views Thread by lumer26 | last post: by
reply views Thread by lumer26 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.