WebSocket异常，帮忙找找异常发生在哪里，几行代码，我找了两天都没找出来。

[Rimifon]

调用方：

try { socket.Send(strMsg); }
catch(Exception err) {
// 这里的err是 “未将对象引用设置到对象的实例。”
}

类封装部分代码：

		public async Task Send(string userMsg) {
			// 监控 wsCtx.IsClientConnected 不是 false 就是 true，所以 wsCtx 不是被释放状态
			if(!wsCtx.IsClientConnected) { OnMessage("Lose", 0); return; }
			// 这里如果不用 try，调用方就有可能出现“索引超出了数组界限”的错误，加了 try 就是“未将对象引用设置到对象的实例。”
			try { var buffer = new ArraySegment<byte>(Encoding.UTF8.GetBytes(userMsg));
			await wsCtx.WebSocket.SendAsync(buffer, WebSocketMessageType.Text, true, CancellationToken.None);
			} catch { }
		}
		
		private void OnMessage(string msg, int code) {
			try { MessageBack.Invoke(msg, code); } catch { }
		}

[Rimifon]

大概明白 try catch 机制了，如果没有 catch 具体的错误类型，那么外部如果使用了 try catch，仍然是可以 catch到错误的。 如果内部已经 try，外部再 try 一次，那么捕获到异常后就中断当前处理了；如果外部不再加 try ，那么有异常那行语句就能继续往后执行。

[三楼の郎]

错误要从源头抓起

[以专业开发人员为伍]

对于同一个程序，不要动不动就想“吃掉异常”。程序分Debug和Release版本，Debug版本就是要尽可能早地让bug跳出来，被调试器捕获。程序运行异常要抛出给程序的最外层，统一的对话框封装一下然后提示给用户就可以了。你用 try....catch 代码不但让你自己丧失了 debug 的技术能力，而且你还进一步让系统“带毒运行”，造成后续才发生的“莫名其妙”的bug，实际上都是你 try...catch 想对调用方隐瞒自己的代码问题、反而搞出来的 bug。对待这类问题，正确的做法是删除 try.....catch，尽早发现 bug，并且认真发现你的代码的问题，而不是用 try....catch 语句来“隐藏bug”去骗调用者（实际上后续bug都是你另外又制造出来的）。

[Rimifon]

我也想这样，但是 await wsCtx.WebSocket.SendAsync 这个方法老是报 “未将对象引用设置到对象的实例。”的异常，让人摸不着头脑。 wsCtx.IsClientConnected 是 true， wsCtx.WebSocket.State 是 Open，仍然会抛这个异常，我还能咋办。

[Rimifon]

然后，没装VS，C# 部分我是用记事本写出来的，就几行代码，编译成 dll 给 javascript 调用的，主要业务处理在 javascript 里面。 正常情况下不会报异常，就是20来个人连线的样子，每1分钟左右出一个这样的异常，有时运气好，半个小时都没有。

[Rimifon]

socket 肯定不是被释放对象，因为异常发生时，监控 socket.wsCtx 连接状态，不是 true 就是 false

[Rimifon]

需要解决的问题是，类封装里面都用了 try了，为什么还会有异常跑到 调用方。这个异常发生在哪。