如何查看MC的崩溃报告（2）

上一篇我们通过暮色崩溃看到了一些基本的东西，也有人向我提出了意见——

at twilightforest.block.ColorHandler.lambda$init$13(ColorHandler.java:266) 

（java：266）我一开始以为是个错误码（类似Windows的蓝屏错误码），其实它是color handler这个类中，第266行代码出错。

java.lang.ClassCastException：类型转换异常（但还是异常嘛）

这一篇我们来看一看一些常见的异常。

http://paste.ubuntu.com/25678716/ （看这里看这里！）

28行以前的coremod are present依旧是废话。

35行异常：java.lang.RuntimeException: java.lang.NullPointerException，即为空指针异常——大家可能会奇怪，Java哪来的指针？当然，我们管Java都叫“引用”（对一个对象的引用），而不叫指针，不过pointer这个基本概念是有的。

空指针异常就是该对象没有被实例化（为空）时的引用异常——我们都是单身狗对吧，哪里找对象给你引用去？没有对象，自然很崩溃啦。

55-57行：caused by：java.lang.NullPointerException

at mapwriter.BlockColourGen.genBlockColours(BlockColourGen.java:176) 

at mapwriter.Mw.reloadBlockColours(Mw.java:289)

caused by：xxx——由空指针引发的异常，at（在）mapwriter（一个小地图mod）之下的BlockColourGen类异常，由字面意思很容易读出，这是地图在获取方块颜色时出现的错误。

这只是个形象比喻，普通玩家不需要知道原理，因为这种崩溃一般发生在某一特定事件被触发，比如挖掉某根管道啦，从箱子/储物桶中拿取物品啦，要骑上某匹被诅咒的马啦……

说解决也简单，避开这一事件，例如用管道或者线缆，或者假玩家（比如Extra Utilities 2的mechanical user以及各种挖矿机，都是虚拟出来的假玩家）代替玩家进行资源获取与物流；例如把出故障的实体打掉（如果是打掉时出了问题就先留着）；例如不进入进而删除故障区块——总之，别啥崩溃你非得干啥，这不是欠的吗？同时到作者的GitHub源码库下提出issue（问题），等待修复。

以下均为废话，仅显示你的系统和当前模组。

好，让我们看看下一个，应该说是一类崩溃：发生在游戏启动前（窗口没出现）的崩溃，这种崩溃是不会生成crash-report的，但是所有的信息都会在fml-cilent-latest.log下显示，HMCL等启动器的日志即对应这个文件。处在MC目录（.minecraft）下的logs文件夹中，一般都是八云紫的裹脚布——又臭又长，仅适合开发者使用（除非游戏没开启就崩溃，否则请不要把这堆玩意给复制出来！），但它确实是最完整的信息，即使是crash report，也只是从这个日志中提取了崩溃时发生的错误，但是也足够了。

由于没开启就崩溃，日志不会很长，一般导致崩溃的是如下几个原因：

libraries（库文件）下载不完全：一般是网络问题导致的，日志中会显示“log4j”这样的字符，这种情况可以更换启动器的下载源（例如HMCL启动器，启动器设置-下载源中将官方换成bangbang93），开启VPN（科学上网），或者直接跟别人要个现成的libraries文件夹并在启动器里开启“不使用公共路径”。

Java，显卡驱动，高清修复等问题：前两者都是MC运行的基本盘，Java版本过旧容易引发问题，1.12更是强制使用Java 8；显卡驱动也有影响，一段时间前NVIDIA的378.49驱动直接无差别引发了MC的崩溃；高清修复虽然不是，但是它相当程度修改了原版代码，加上它bug多还不开源，一直受人诟病。

还有一些古董级电脑，其显卡连OpenGL都无法支持的，还是趁早砸电脑吧。

一些coremod（核心模组）引发的崩溃：这种崩溃其实非常少见，但核心模组毕竟是在MC的类加载之前就对其做出改动的，不排除作者没写好的可能，解决方法也很简单，更新或者删除日志中所提到的coremod。

下一个崩溃类型：没有有价值信息的玄学崩溃

http://paste.ubuntu.com/25679329/（看这里看这里！）

java.lang.IndexOutOfBoundsException: Index: 416, Size: 416，意为“数组越界”，这就很头疼了，我玩的好好的哪来的越界？

下面几行，如at java.util.ArrayList.rangeCheck(Unknown Source)

at java.util.ArrayList.remove(Unknown Source)，发生在Java和MC本身的问题，无法预防也无法修复。

56行的affected level或许有帮助？然而崩溃点发生在（0,0）区块，是大多数人直接建家的所在，而且看里面一片的0，真的是家里爆炸了？

不过这种崩溃，来得突然去得也快，发生之后，首先重启，重启好了自然可以继续玩下去；如果重启也失败，试着找回原来备份的存档并替换原来的存档（推荐使用FTB Utilities或者Aroma Backup自动备份），如果找不到任何有价值的备份，只能删区块删存档了。

下一个崩溃类型：模组冲突引发的崩溃

现在的主流模组，尤其是欧美系的EU啊，RF啊等模组，稳定性都没啥说，但日系模组（如slashblade，就是拔刀剑）bug很多，不够稳定，崩溃报告里如果出现这样的模组，想想是不是该删模组了。

当然欧美系内部也有害群之马，比如下面的崩溃：

http://paste.ubuntu.com/25679409/（看这里看这里！）

at com.creativemd.creativecore.common.world.WorldChunkedTileEntityList.get(WorldChunkedTileEntityList.java:162) 

at com.creativemd.creativecore.common.world.WorldChunkedTileEntityList.get(WorldChunkedTileEntityList.java:21)

at teamroots.embers.EventManager.onRenderAfterWorld(EventManager.java:601)

一个叫creativecore的模组（creativemd是这个模组作者的名字，很多模组作者会把自己的名字放在模组名之前，因为这个作者/团队会有不止一个模组作品）和一个由teamroots开发的embers都报了异常，那么谁是罪魁祸首呢？

这就需要玩家对模组本身的性质有所了解了——creative core是一个装饰小方块模组little tiles的前置，这个模组本身不稳定，尤其是中途加入已经运行过一段时间的模组包时容易引发崩溃。

而embers（余烬）作为一个拥有各种道具的综合性模组，稳定性高于little tiles，该干掉谁应该心里有数了吧。

玩家在选择模组的时候，要尽可能选择欧美系作者（他们的模组一般搭载在curse上）的著名模组，能用大不用小，比如Ender IO（末影接口）的玄钢斧，Draconic Evolution（龙之进化）的神龙斧，Tinker's Construct（匠魂）的伐木斧，Gregtech（格雷科技）的斧头，Botania（植物魔法）的泰拉斧，Mekanism（通用机械）的原子分解机，个个都有连锁范围砍树功能，干嘛多装一个砍树模组？、

模组挑选可以参考此贴：https://tieba.baidu.com/p/5297039388（更新中）

小结：面对崩溃时，你或许要准备好这些：

重启游戏；

更新Java，显卡驱动；

搞清楚你包里的模组特性，更新/卸载报告里提到的异常模组。（并不推荐卸载）

一个WE（创世神）插件或者其他的手段以变更出错的区块；

已经备份的近期存档；

一颗冷静的心。