kl中的錯誤處理
之前我一直說錯誤處理是kl里的軟肋，由于一直在關(guān)注一些具體功能的改進(jìn)，也沒有對
這方面進(jìn)行改善。
我這里所說的錯誤處理，包括語言本身和作為庫本身兩方面。
語言本身指的是對于腳本代碼里的各種語法錯誤、運(yùn)行時錯誤等的處理。好的處理應(yīng)該
不僅僅可以報告錯誤，而且還能忽視錯誤讓處理過程繼續(xù)。
而把kl解釋器作為一個庫使用時，庫本身也應(yīng)該對一些錯誤情況進(jìn)行報告。
整體上，kl簡單地通過回調(diào)函數(shù)指針來把錯誤信息傳給庫的應(yīng)用層。而因?yàn)槲蚁Ｍ麄€
kl實(shí)現(xiàn)的幾層（詞法分析、語法分析、符號表、解釋器等）可以盡可能地獨(dú)立。例如雖然語
法分析依賴于詞法分析（依賴于詞法分析提供的接口），但是因?yàn)樵~法分析并不對語法分析
依賴，所以完全可以把詞法分析模塊拿出來單獨(dú)使用。所以，在日志方面，我?guī)缀鯙槊恳粚?br>都附加了個error_log函數(shù)指針。
而用戶層在通過kllib層使用整個庫時，傳入的回調(diào)函數(shù)會被間接地傳到詞法分析層。
實(shí)際上，當(dāng)kl作為一個庫時，kllib正是用于橋接庫本身和用戶層的bridge。
另一方面，語言本身在處理錯誤的腳本代碼時，錯誤分為幾大類型層次：
1.詞法錯誤 lex error，如掃描字符串出錯
2.語法錯誤 syntax error，整理語法樹時出錯
3.運(yùn)行時錯誤 runtime error，在解釋執(zhí)行代碼時出錯
4.庫錯誤 lib error，發(fā)生在kllib這個bridge層的錯誤
kl在報告錯誤信息時，會首先附加該錯誤是什么類型的錯誤。
這里最麻煩的是語法錯誤的處理。因?yàn)檎Z法分析時發(fā)生錯誤的可能性最大，錯誤類型也
有很多。例如你少寫了分號，少寫了括號，都會導(dǎo)致錯誤。這個階段發(fā)生錯誤不僅要求能準(zhǔn)
確報告錯誤，還需要忽略錯誤讓整個過程盡量正確地下去。
語法分析階段最根本的就是符號推導(dǎo)（單就kl的實(shí)現(xiàn)而言），所謂的符號推導(dǎo)是這樣一
個過程，例如有賦值語句：a = 1;語法分析時，語法分析器希望（所謂的推導(dǎo)）等號后面會
是一個表達(dá)式，當(dāng)分析完了表達(dá)式后，又希望接下來的符號(token)是分號作為該語句的結(jié)
束。
所以，klparser.c中的syn_match正是完成這個過程。每次你傳入你希望的符號，例如
分號，該函數(shù)就檢查詞法分析中當(dāng)前符號(token)是否是分號。當(dāng)然，對于正確的腳本代碼，
它是一個分號，但是如果是錯誤的代碼，syn_match就會打印諸如：
>>syntax error->unexpected token-> ....
即當(dāng)前的符號是不被期望的。
上面完成了錯誤的檢測。對于錯誤的忽略，或者更高級點(diǎn)地對錯誤的校正，kl中處理得
比較簡單，即：直接消耗掉這個不是期望中的符號。例如：
a = 1 /* 忘加了分號 */
b = 1;
上面兩句代碼被處理時，在處理完a=1后，發(fā)現(xiàn)當(dāng)前的符號(token)b(是一個ID token)不
是期望(expect)中的分號，首先報告b不是期望的符號，然后kl直接掠過b，獲取下個符號=。
然后處理a=1這個過程結(jié)束。當(dāng)然，下次處理其他語句時，發(fā)現(xiàn)=符號，又會繼續(xù)發(fā)生錯誤。
錯誤信息中比較重要的還有行號信息。之前kl這方面一直存在BUG，我在寫貪食蛇例子
的時候每次新加代碼都不敢加太多。因?yàn)榻忉屍鲌蟾娴腻e誤行號總是錯誤的，我只能靠有沒
有錯誤來找錯誤，而不能通過錯誤信息找錯誤。
行號信息被保存在詞法分析狀態(tài)中(lexState:lineno)，語法分析中獲取token時，會取
出當(dāng)前的行號，保存到語法樹樹節(jié)點(diǎn)中。因?yàn)榘ń忉屇K都是基于樹節(jié)點(diǎn)的，所以詞法分
析語法分析解釋器三層都可以準(zhǔn)確報告行號。
但是之前解釋器報告的行號始終很詭異。癥結(jié)在于我在載入腳本代碼文件時，以rb方式
載入，即二進(jìn)制形式。于是，在windows下，每行文本尾都會有\(zhòng)r\n兩個字符。而在詞法分
析階段對于行號的增加是：
case '\n':
case '\r':
ls->lineno ++;
不同OS對于文本文件的換行所添加的字符都不一樣，例如windows用\r\n，unix系用\n
，貌似Mac用\r。所以，詞法分析這里寫應(yīng)該可以準(zhǔn)確地處理行號。
但是對于windows，這里就直接將行號增加了兩次，所以也就導(dǎo)致了行號出錯的問題。查
了下文檔，發(fā)現(xiàn)以文本方式打開文件("r")，調(diào)用fread函數(shù)讀入文件內(nèi)容時，就會自動把
\r\n替換為\n。
代碼改后，又出問題。這個時候，通過fseek和ftell獲取到的文件尺寸，貌似包括了
\r\n，而fread出來的內(nèi)容卻因?yàn)樘鎿Q\r\n為\n而沒有這么多。
不過文件載入不屬于kl庫本身，kl只接收以字符串形式表示的腳本代碼，所以也算不了
核心問題。
同樣，最新代碼可以從google SVN獲取。當(dāng)然，我也在考慮是否換一個新的項(xiàng)目地址。