游戏服务器开发指南（八）：合理应对异常

大家好！我是长三月，一位在游戏行业工作多年的老程序员，专注于分享服务器开发相关的文章。

本文是通用程序设计主题下的第二篇。这个主题主要探讨如何编写高效、健壮、易读的游戏业务代码，每篇从一个小点切入。本次讨论的要点是：如何合理地应对异常。

异常（错误处理）是游戏服务器开发中绕不开的一个话题。合理地处理异常，能够将故障对玩家的影响降到最低水平，快速从错误中恢复，并提供充足的信息，避免以后再出现类似的问题。

有些编程语言（例如Golang）会把异常和错误分开，这里为了方便说明，用异常来统一指代这两种类型。因为这两者在处理方法上是相通的。

总的原则是根据异常的严重程度和影响范围在不同层次处理。对于服务器启动时的严重异常，应向顶层抛出，立即中止服务器运行；而对于仅影响个别玩家的异常，应及时捕获异常，避免影响其他玩家。

看下面一个Java写的例子。服务器在启动时调用start方法做一些初始化工作，其中包括对于Redis客户端的初始化：测试Redis服务器是否可连通，如果可连通初始化连接等。如果发现Redis服务器连接失败，抛出异常，这里不会对异常捕捉，而是逐级抛到顶层，让服务器进程中断运行。

这样做的好处是让程序员及时检查问题并做修正，避免后续问题的发生。试想，如果我们改成捕捉异常并恢复程序运行，那么当服务器启动完成后玩家正常进入，可是需要使用到Redis存取数据时才发现功能不可用，必然会引起玩家的不满。所以，对于这种影响全局的严重问题，不如在停服重启的时候就彻底解决好，解决了再对玩家开放服务器。

这种异常处理策略被称为快速失败（fail-fast），即检测到异常后直接抛出并中止程序运行。它适用于严重而且无法恢复的异常情形，好处是能第一时间发现和定位问题，并且避免错误对后续逻辑的影响。JDK中也有对fail-fast思想的运用，例如ArrayList是一个非线程安全的容器，如果在使用for-each遍历元素的同时又修改了它的结构，那么会第一时间抛出ConcurrentModificationException，快速而干净地失败，而不是冒着在未来不确定的时间出现不确定行为的风险。

对于全局性的严重异常，我们固然要fail-fast。但是对于仅影响部分玩家或者部分场合的异常，我们要及时捕捉并恢复，避免不恰当地扩大影响范围。

在游戏中经常会有活动排行榜结算的场景。活动结束时，按照参与活动玩家在排行榜的名次依次发奖。通常这样的操作放在定时任务中执行。如果某一个玩家发奖出现异常，我们需要及时捕捉异常并记录详细的日志，避免影响到其他玩家。

对比一下，如果我们不对单个玩家发奖捕捉异常，那么出现异常时会导致所有人的发奖失败，势必会引发更多玩家不满，而且需要做更多补偿。由于我们及时捕捉异常，因此发奖失败仅仅被限制在单个玩家范围内，事后处理也要容易得多。

另一个限制异常影响范围的例子是服务器战斗。在逐帧进行的服务器战斗中，每帧运算出现异常时，需要及时捕捉，这样只会影响当前帧，而不会导致战斗直接退出，甚至战斗线程挂掉。

捕捉异常时，我们要在日志记录充足的信息，以便后续追踪修复问题和做线上处理，不要忽略异常而什么都不记录。要记录的信息应包括完整的异常堆栈、角色id以及其他重要信息。例如上面提到过的发奖失败日志，除了异常堆栈，还应包括角色id和排名，这样方便事后为对应玩家做补偿。