DuckT 我要的效果是一个小功能出问题，不能影响其他的功能，客户端肯定是能正常游戏的，只是那个请求在服务器崩了，客户端还是能玩其他功能的。
那你可以默认返回0个金币，把真正问题藏起来，这样会导致很多玩家都会出现这个“小问题”。这样处理就是给自己找麻烦
DuckT 我的意思不是如何隐藏问题，是客户端在服务器回复超时的情况下怎么处理超时的请求，要不要在requestCallbacks去掉超时的请求，真正问题在服务器那儿肯定有log的。
IxbxAxx 那你客户端网络不好的时候怎么办呢？客户端怎么判断是服务器出了问题，还是单纯网络不好？
DuckT 发包确认回复是kcp的事儿。session断开重新连接那requestCallbacks会清理。
写了测试代码试了么，rpc请求都是try包住的， 异常也会被捕捉，再错误回调回来的，应该不会出现你们说得这个问题的呀
evalli 我在客户端debug，在服务器handler崩了后没收到回复啊
IxbxAxx 应该不会呀，你看下AMRpcHandler里面的HandlerAsync这里有没有执行到。 里面的try catch会捕捉执行结果
evalli 我发的是IActorLocationRequest，
catch完后就throw了。
所以就走不到下面的逻辑，发不回客户端。
evalli 非Actor消息确实能把异常发到客户端😂
IxbxAxx 刚看了下，actorLocation是不会返回，返回的error级别太高，抛异常中断了，可能得问下作者这里为啥要采用异常中断😀
evalli actor消息是进程之间的消息，也就是说，actor消息都是服务器内部通讯用的
同事写了个没有收到服务器回复就客户端转圈圈，然后搭配上这个actorLocation请求崩了就不回复的问题，无论哪一个请求崩了就会直接把客户端卡死😅
等大佬看这篇帖子
服务端都崩了，客户端还跑有啥意义
egametang 我想的是在某个功能崩了的情况下不停服，然后客户端还能接着玩别的功能🤣
IxbxAxx 你以为是web呢，游戏功能都是交织在一起的，怎么分得开
egametang 他应该说得是抛exception，不是进程崩溃的情况下，只是其中一条协议报exception，不希望影响其他的功能,但是这也存在问题，万一那条协议影响面很大，继续玩可能产生不可预知的问题。
服务器抛异常那不会影响客户端
egametang actorLocation请求如果抛异常不会回复到客户端，同事写了个没有收到服务器回复就客户端转圈圈，然后就卡死了
IxbxAxx 如果只是简单的 请求响应(一来一回)逻辑也还好说吧 超时响应处理下
比如排行榜的节点宕机了, 拿不到数据, 大不了客户端排行榜是空的, 其他如战斗系统逻辑还是正常的.
但是要求请求响应的前后状态, 有关联的逻辑就不好处理了呀. 比如玩家组队匹配战斗, 匹配服出问题了, 后续的逻辑也都不能继续了吧. 客户端没有收到响应也不知道什么情况, 如何做出合理的表现? 问题很多… 直接抛错可能才是最合理的, 毕竟错了就是错了
IxbxAxx 刚看了ET8已经修复这个问题了 ，同步下就可以了
