IrcClient.HandleISupportParameter throws when connecting to due to a missing paramName parameter

Bug #897286 reported by Jeremy Brayton on 2011-11-28
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Here's the stacktrace, which doesn't really do anything other than point to the method:

   at IrcDotNet.IrcClient.HandleISupportParameter(String paramName, String paramValue)
   at IrcDotNet.IrcClient.ProcessMessageReplyBounceOrISupport(IrcMessage message)
   at IrcDotNet.IrcClient.ReadMessage(IrcMessage message, String line)
   at IrcDotNet.IrcClient.ReceiveCompleted(Object sender, SocketAsyncEventArgs e)
   at System.Net.Sockets.SocketAsyncEventArgs.OnCompleted(SocketAsyncEventArgs e)
   at System.Net.Sockets.SocketAsyncEventArgs.OnCompletedInternal(SocketAsyncEventArgs e)
   at System.Net.Sockets.SocketAsyncEventArgs.FinishOperationSuccess(SocketError socketError, Int32 bytesTransferred, SocketFlags flags)
   at System.Net.Sockets.Socket.AsyncCallback(IAsyncResult ar)
   at System.Net.LazyAsyncResult.InvokeCallback(Boolean asyncCompletion)
   at System.Net.Sockets.Socket.SocketAsyncRequestManager.WorkerThread.doWork()
   at System.Net.Sockets.Socket.SocketAsyncRequestManager.WorkerThread.doWorkI(Object o)
   at System.Threading.ThreadPool.WorkItem.WaitCallback_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadPool.WorkItem.doWork(Object o)
   at System.Threading.Timer.ring()

Webchat isn't a normal network in that it mostly uses ConferenceRoom which doesn't seem to conform to RFC standards most of the time. I can't tell if the problem is it's passing in empty paramNames just once every single time it's called.

What happens for the connection is the client triggers Connected and Registered events but it is NOT getting to NetworkInformationReceived, which I use to start processing channel joins.

I'd also question using a hard throw in this instance for HandlesISupportParameter. If a network incorrectly calls this or doesn't support the call, should it drop the connection or continue gracefully? I would think continue gracefully is the better option and I can't do that if it triggers the Error event.

Lastly, I read the Error event more as a FatalException where IrcDotNet cannot do anything else for the client that raises it. If this is false, perhaps introducing an IsHandled property in IrcErrorEventArgs where internal methods set this to true. This would let me easily distinguish IrcDotNet errors versus what I normally see which are exceptions in my code that bubble up.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers