tags:

views:

203

answers:

3

I am developing a console-based .NET application (using mono). I'm using asynchronous I/O (Begin/EndReceive).

I'm in the middle of a callback chain several layers deep, and if an exception is thrown, it is not being trapped anywhere (having it bubble out to the console is what I would expect, as there is currently no exception handling).

However, looking at the stack trace when I log it at the point where it occurs, the stack doesn't show it reaching back to the initial point-of-execution.

I've tried the AppDomain.UnhandledException trick, but that doesn't work in this situation.

System.ArgumentOutOfRangeException: Argument is out of range.
Parameter name: size
  at System.Net.Sockets.Socket.BeginReceive (System.Byte[] buffer, Int32 offset, Int32 size, SocketFlags socket_flags, System.AsyncCallback callback, System.Object state) [0x00000] 
  at MyClass+State.BeginReceive () [0x00000]
+2  A: 

I believe any error generated during an asynchronous call should be thrown upon calling the EndAction method (EndReceive in your case). At least, this is what I've experienced using the CLR (MSFT) implementation, and Mono should be doing the same thing, although it may perhaps be slightly buggy here (consider this as unlikely however). If you were in Visual Studio, I would recommend you turn on the option for catching all exceptions (i)n the Debug > Exceptions menu) - perhaps there is a similar option in whatever IDE you are using?

Noldorin
During the asynchronous call, yes. You can use Socket.EndReceive(IAsyncResult, SocketError) to retrieve a SocketError that occurred. But in this case, BeginReceive never starts, as my 'size' argument is out-of-range.
osi
Ah sorry, didn't notice that. In this case, have you tried running the code on Windows under the CLR? That would help narrow down whether it's a Mono issue at least.
Noldorin
Not yet, but I will :)
osi
A: 

From the look of the stack, the exception is being thrown in the BeginReceive, so that particular I/O operation is not being initiated at all.

The default behaviour (since CLR2.0) of an unhandled exception on a thread-pool thread is to terminate the process, so if you are not seeing this, then something is catching the exception.

Nick Gunn
How do I determine what may be catching it?
osi
Sorry, I missed the bit about it being Mono, and I don't know if this affects things as I have no experience of this platform. I would break at the point the exception is thrown then single-step to where it is caught. It maybe that your version of Mono silently swallows thread-pool exceptions.
Nick Gunn
A: 

Using Microsoft's .NET usually most exceptions thrown during async calls are raised within the async callback method, except few cases. To handle the rest I usually set a timeout callback method.

Jader Dias