上一篇我們通過暮色崩潰看到了一些基本的東西，也有人向我提出了意見——

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

（java：266）我一開始以為是個錯誤碼（類似Windows的藍屏錯誤碼），其實它是color handler這個類中，第266行代碼出錯。

java.lang.ClassCastException：類型轉(zhuǎn)換異常（但還是異常嘛）

這一篇我們來看一看一些常見的異常。

http://paste.ubuntu.com/25678716/ （看這里看這里?。?/p>

28行以前的coremod are present依舊是廢話。

35行異常：java.lang.RuntimeException: java.lang.NullPointerException，即為空指針異?！蠹铱赡軙婀?，Java哪來的指針？當然，我們管Java都叫“引用”（對一個對象的引用），而不叫指針，不過pointer這個基本概念是有的。

空指針異常就是該對象沒有被實例化（為空）時的引用異?！覀兌际菃紊砉穼Π桑睦镎覍ο蠼o你引用去？沒有對象，自然很崩潰啦。

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

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

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

caused by：xxx——由空指針引發(fā)的異常，at（在）mapwriter（一個小地圖mod）之下的BlockColourGen類異常，由字面意思很容易讀出，這是地圖在獲取方塊顏色時出現(xiàn)的錯誤。

這只是個形象比喻，普通玩家不需要知道原理，因為這種崩潰一般發(fā)生在某一特定事件被觸發(fā)，比如挖掉某根管道啦，從箱子/儲物桶中拿取物品啦，要騎上某匹被詛咒的馬啦……

說解決也簡單，避開這一事件，例如用管道或者線纜，或者假玩家（比如Extra Utilities 2的mechanical user以及各種挖礦機，都是虛擬出來的假玩家）代替玩家進行資源獲取與物流；例如把出故障的實體打掉（如果是打掉時出了問題就先留著）；例如不進入進而刪除故障區(qū)塊——總之，別啥崩潰你非得干啥，這不是欠的嗎？同時到作者的GitHub源碼庫下提出issue（問題），等待修復。

以下均為廢話，僅顯示你的系統(tǒng)和當前模組。

好，讓我們看看下一個，應該說是一類崩潰：發(fā)生在游戲啟動前（窗口沒出現(xiàn)）的崩潰，這種崩潰是不會生成crash-report的，但是所有的信息都會在fml-cilent-latest.log下顯示，HMCL等啟動器的日志即對應這個文件。處在MC目錄（.minecraft）下的logs文件夾中，一般都是八云紫的裹腳布——又臭又長，僅適合開發(fā)者使用（除非游戲沒開啟就崩潰，否則請不要把這堆玩意給復制出來！），但它確實是最完整的信息，即使是crash report，也只是從這個日志中提取了崩潰時發(fā)生的錯誤，但是也足夠了。

由于沒開啟就崩潰，日志不會很長，一般導致崩潰的是如下幾個原因：

libraries（庫文件）下載不完全：一般是網(wǎng)絡問題導致的，日志中會顯示“l(fā)og4j”這樣的字符，這種情況可以更換啟動器的下載源（例如HMCL啟動器，啟動器設置-下載源中將官方換成bangbang93），開啟VPN（科學上網(wǎng)），或者直接跟別人要個現(xiàn)成的libraries文件夾并在啟動器里開啟“不使用公共路徑”。

Java，顯卡驅(qū)動，高清修復等問題：前兩者都是MC運行的基本盤，Java版本過舊容易引發(fā)問題，1.12更是強制使用Java 8；顯卡驅(qū)動也有影響，一段時間前NVIDIA的378.49驅(qū)動直接無差別引發(fā)了MC的崩潰；高清修復雖然不是，但是它相當程度修改了原版代碼，加上它bug多還不開源，一直受人詬病。

還有一些古董級電腦，其顯卡連OpenGL都無法支持的，還是趁早砸電腦吧。

一些coremod（核心模組）引發(fā)的崩潰：這種崩潰其實非常少見，但核心模組畢竟是在MC的類加載之前就對其做出改動的，不排除作者沒寫好的可能，解決方法也很簡單，更新或者刪除日志中所提到的coremod。

下一個崩潰類型：沒有有價值信息的玄學崩潰

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

java.lang.IndexOutOfBoundsException: Index: 416, Size: 416，意為“數(shù)組越界”，這就很頭疼了，我玩的好好的哪來的越界？

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

at java.util.ArrayList.remove(Unknown Source)，發(fā)生在Java和MC本身的問題，無法預防也無法修復。

56行的affected level或許有幫助？然而崩潰點發(fā)生在（0,0）區(qū)塊，是大多數(shù)人直接建家的所在，而且看里面一片的0，真的是家里爆炸了？

不過這種崩潰，來得突然去得也快，發(fā)生之后，首先重啟，重啟好了自然可以繼續(xù)玩下去；如果重啟也失敗，試著找回原來備份的存檔并替換原來的存檔（推薦使用FTB Utilities或者Aroma Backup自動備份），如果找不到任何有價值的備份，只能刪區(qū)塊刪存檔了。

下一個崩潰類型：模組沖突引發(fā)的崩潰

現(xiàn)在的主流模組，尤其是歐美系的EU啊，RF啊等模組，穩(wěn)定性都沒啥說，但日系模組（如slashblade，就是拔刀劍）bug很多，不夠穩(wěn)定，崩潰報告里如果出現(xiàn)這樣的模組，想想是不是該刪模組了。

當然歐美系內(nèi)部也有害群之馬，比如下面的崩潰：

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開發(fā)的embers都報了異常，那么誰是罪魁禍首呢？

這就需要玩家對模組本身的性質(zhì)有所了解了——creative core是一個裝飾小方塊模組little tiles的前置，這個模組本身不穩(wěn)定，尤其是中途加入已經(jīng)運行過一段時間的模組包時容易引發(fā)崩潰。

而embers（余燼）作為一個擁有各種道具的綜合性模組，穩(wěn)定性高于little tiles，該干掉誰應該心里有數(shù)了吧。

玩家在選擇模組的時候，要盡可能選擇歐美系作者（他們的模組一般搭載在curse上）的著名模組，能用大不用小，比如Ender IO（末影接口）的玄鋼斧，Draconic Evolution（龍之進化）的神龍斧，Tinker's Construct（匠魂）的伐木斧，Gregtech（格雷科技）的斧頭，Botania（植物魔法）的泰拉斧，Mekanism（通用機械）的原子分解機，個個都有連鎖范圍砍樹功能，干嘛多裝一個砍樹模組？、

模組挑選可以參考此貼：https://tieba.baidu.com/p/5297039388（更新中）

小結(jié)：面對崩潰時，你或許要準備好這些：

重啟游戲；

更新Java，顯卡驅(qū)動；

搞清楚你包里的模組特性，更新/卸載報告里提到的異常模組。（并不推薦卸載）

一個WE（創(chuàng)世神）插件或者其他的手段以變更出錯的區(qū)塊；

已經(jīng)備份的近期存檔；

一顆冷靜的心。