Exception handling issue in async-functions about webchannel.net

[chhaude]

The behavior now is better. However, one issue remains in when trying to connect to an unreachable host:
The event OnError cannot be connected to before the connection is being established.

Detailed description:
When the constructor WebChannelTcpSocketTransport is called, the connection is established even before any event handlers can be connected to.

public WebChannelTcpSocketTransport(string host, int port, Action<WebChannelTcpSocketTransport> connectedCallback) {
            sock = new TcpClient();
            sock.BeginConnect(host, port, new AsyncCallback(ClientConnected), connectedCallback);
        }

Consequently, the OnError handler is for sure not set, so in any case only the message "An error occured while attempting to connect!" will appear, and OnError(this, args); will never be called.

void ClientConnected(IAsyncResult ar)
        {
            var callback = (Action<WebChannelTcpSocketTransport>) ar.AsyncState;
            try {
                sock.EndConnect(ar);
            } catch (Exception e) {
                Console.Error.WriteLine("An error occured while attempting to connect!");
                if (OnError != null) {
                    var args = new UnhandledExceptionEventArgs(e, false);
                    OnError(this, args);
                }
                return;
            }
.
.
.

I suggest to change the architecture a little, so that the constructor doesn't immediately establish the connection, but rather returns the object. Then event handlers can be set, and afterwards the connection can be established by a publish function connect() or similar.

[chhaude]

I found another problem: When calling the Dispose()-function and data is received at that time, the exception handlers don't catch all exceptions:

Unbehandelte Ausnahme: System.ObjectDisposedException: Auf das verworfene Objekt kann nicht zugegriffen werden.
Objektname: "System.Net.Sockets.Socket".
   bei System.Net.Sockets.Socket.Poll(Int32 microSeconds, SelectMode mode)
   bei QWebChannel.WebChannelTcpSocketTransport.IsSocketConnected(Socket s)
   bei QWebChannel.WebChannelTcpSocketTransport.DataAvailable(IAsyncResult ar)
   bei System.Net.LazyAsyncResult.Complete(IntPtr userToken)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   bei System.Net.ContextAwareResult.Complete(IntPtr userToken)
   bei System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
   bei System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
   bei System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

The call to IsSocketConnected fails, and this is a function that is not within a try-block.
The same happens for the Disconnect()-function.

I believe we need to fix those problems before we can really release the library for general use.

[msarehn]

These should be fixed now with the latest two commits.