互聯(lián)網(wǎng)/程序員/技術(shù)/資料共享
作者：琴水玉 來源：https://cnblogs.com/lovesqcc/p/4319594.html
在程序中打錯(cuò)誤日志的主要目標(biāo)是為更好地排查問題和解決問題提供重要線索和指導(dǎo)。 但是在實(shí)際中打的錯(cuò)誤日志內(nèi)容和格式變化多樣，錯(cuò)誤提示上可能殘缺不全、沒有相關(guān)背景、不明其義，使得排查解決問題成為非常不方便或者耗時(shí)的操作。 而實(shí)際上，如果編程的時(shí)候稍加用心，就會(huì)減少排查問題的很多無用功。 在闡述如何編寫有效的錯(cuò)誤日志之前，了解錯(cuò)誤是怎么產(chǎn)生的，非常重要。
錯(cuò)誤是如何煉成的
對(duì)于當(dāng)前系統(tǒng)來說， 錯(cuò)誤的產(chǎn)生由三個(gè)地方引入：
1.上層系統(tǒng)引入的非法參數(shù)。對(duì)于非法參數(shù)引入的錯(cuò)誤， 可以通過參數(shù)校驗(yàn)和前置條件校驗(yàn)來截獲錯(cuò)誤；
2.與下層系統(tǒng)交互產(chǎn)生的錯(cuò)誤。與下層交互產(chǎn)生的錯(cuò)誤， 有兩種：
a.下層系統(tǒng)處理成功了，但是通信出錯(cuò)了， 這樣會(huì)導(dǎo)致子系統(tǒng)之間的數(shù)據(jù)不一致；
對(duì)于這種情況， 可以采用超時(shí)補(bǔ)償機(jī)制，預(yù)先將任務(wù)記錄下來，通過定時(shí)任務(wù)在后續(xù)將數(shù)據(jù)訂正過來。
更好的設(shè)計(jì)方案 ？
b.通信成功了，但是下層處理出錯(cuò)了。
對(duì)于這種情況， 需要與下層開發(fā)人員溝通， 協(xié)調(diào)子系統(tǒng)之間的交互；
需要根據(jù)下層返回的錯(cuò)誤碼和錯(cuò)誤描述做適當(dāng)?shù)奶幚砘蚪o予合理的提示信息。
無論哪一種情況， 都要假設(shè)下層系統(tǒng)可靠性一般， 做好出錯(cuò)的設(shè)計(jì)考慮。
3.本層系統(tǒng)處理出錯(cuò)。
本層系統(tǒng)產(chǎn)生錯(cuò)誤的原因：
原因一：疏忽導(dǎo)致。
疏忽是指程序員能力完全可避免此類錯(cuò)誤但實(shí)際上沒做到。比如將 && 敲成了 & ， == 敲成了 = ；邊界錯(cuò)誤， 復(fù)合邏輯判斷錯(cuò)誤等。疏忽要么是程序員注意力不夠集中， 比如處于疲倦狀態(tài)、加班通宵、邊開會(huì)邊寫程序；要么是急著實(shí)現(xiàn)功能，沒有顧及程序的健壯性等。 改進(jìn)措施：使用代碼靜態(tài)分析工具，通過單元測(cè)試行覆蓋可有效避免此類問題。 原因二：錯(cuò)誤與異常處理不夠周全導(dǎo)致的。 比如輸入問題。計(jì)算兩個(gè)數(shù)相加， 不僅要考慮計(jì)算溢出問題， 還要考慮輸入非法的情形。對(duì)于前者，可能通過了解、犯錯(cuò)或經(jīng)驗(yàn)就可以避免， 而對(duì)于后者，則必須加以限定，以使之處于我們的智商能夠控制的范圍內(nèi)，比如使用正則表達(dá)式過濾掉不合法的輸入。對(duì)于正則表達(dá)式必須進(jìn)行測(cè)試。對(duì)于不合法輸入， 要給出盡可能詳細(xì)、易懂、友好的提示信息、原因及建議方案。 改進(jìn)措施：盡可能周全地考慮各種錯(cuò)誤情形和異常處理。在實(shí)現(xiàn)主流程之后，增加一個(gè)步驟：仔細(xì)推敲可能的各種錯(cuò)誤和異常，返回合理錯(cuò)誤碼和錯(cuò)誤描述。每個(gè)接口或模塊都有效處理好自己的錯(cuò)誤和異常，可有效避免因場(chǎng)景交互復(fù)雜導(dǎo)致的bug。 譬如，一個(gè)業(yè)務(wù)用例由場(chǎng)景A.B.C交互完成。實(shí)際執(zhí)行A.B成功了，C失敗了，這時(shí)B需要根據(jù)C返回合理的代碼和消息進(jìn)行回滾并返回給A合理的代碼和消息，A根據(jù)B的返回進(jìn)行回滾，并返回給客戶端合理的代碼和消息。這是一種分段回滾的機(jī)制，要求每個(gè)場(chǎng)景都必須考慮異常情況下的回滾。 由于業(yè)務(wù)邏輯耦合緊密， 隨著軟件產(chǎn)品一步步發(fā)展， 各種邏輯關(guān)系錯(cuò)綜復(fù)雜， 難以看到全局狀況， 導(dǎo)致局部修改影響波及到全局范圍，造成不可預(yù)知的問題。 改進(jìn)措施：編寫短函數(shù)和短方法， 每個(gè)函數(shù)或方法最好不超過 50 行。編寫無狀態(tài)函數(shù)和方法， 只讀全局狀態(tài)， 相同的前提條件總是會(huì)輸出相同的結(jié)果， 不會(huì)依賴外部狀態(tài)而變更自己的行為；定義合理的結(jié)構(gòu)、 接口和邏輯段，使接口之間的交互盡可能正交、低耦合；對(duì)于服務(wù)層， 盡可能提供簡(jiǎn)單、正交的接口；持續(xù)重構(gòu)， 保持應(yīng)用模塊化和松耦合， 理清邏輯依賴關(guān)系。對(duì)于有大量業(yè)務(wù)接口相互影響的情況， 必須整理各個(gè)業(yè)務(wù)接口的邏輯流程及相互依賴關(guān)系， 從整體上進(jìn)行優(yōu)化；對(duì)于有大量狀態(tài)的實(shí)體， 也需要梳理相關(guān)的業(yè)務(wù)接口， 整理狀態(tài)之間的轉(zhuǎn)換關(guān)系。 改進(jìn)措施：首先將算法從應(yīng)用中分離出來。若算法有多種實(shí)現(xiàn)， 可以通過交叉校驗(yàn)的單元測(cè)試找出來， 比如排序操作；如果算法具有可逆性質(zhì)， 可以通過可逆校驗(yàn)的單元測(cè)試找出來， 比如加密解密操作。 原因五：相同類型的參數(shù)，傳入順序錯(cuò)誤導(dǎo)致。 比如，modifyFlow(int rx, int tx), 實(shí)際調(diào)用為 modifyFlow(tx,rx) 改進(jìn)措施：盡可能使類型具體化， 該用浮點(diǎn)數(shù)就用浮點(diǎn)數(shù)， 該用字符串就用字符串， 該用具體對(duì)象類型就用具體對(duì)象類型；相同類型的參數(shù)盡可能錯(cuò)開；如果上述都無法滿足， 就必須通過接口測(cè)試來驗(yàn)證， 接口參數(shù)值務(wù)必是不同的。 空指針異常通常是對(duì)象沒有正確初始化， 或者使用對(duì)象之前沒有對(duì)對(duì)象是否非空做檢測(cè)。 改進(jìn)措施：對(duì)于配置對(duì)象， 檢測(cè)其是否成功初始化；對(duì)于普通對(duì)象， 獲取到實(shí)體對(duì)象使用之前， 檢測(cè)是否非空。 原因七：網(wǎng)絡(luò)通信錯(cuò)誤。 網(wǎng)絡(luò)通信錯(cuò)誤通常是因?yàn)榫W(wǎng)絡(luò)延遲、阻塞或不通導(dǎo)致的錯(cuò)誤。網(wǎng)絡(luò)通信錯(cuò)誤通常是小概率事件， 但小概率事件很可能會(huì)導(dǎo)致大面積的故障、 難以復(fù)現(xiàn)的BUG。 改進(jìn)措施：在前一個(gè)子系統(tǒng)的結(jié)束點(diǎn)和后一個(gè)子系統(tǒng)的入口點(diǎn)分別打 INFO 日志。通過兩者的時(shí)間差提供一點(diǎn)線索。 原因八：事務(wù)與并發(fā)錯(cuò)誤。 事務(wù)與并發(fā)結(jié)合在一起， 很容易產(chǎn)生非常難以定位的錯(cuò)誤。 改進(jìn)措施：對(duì)于程序中的并發(fā)操作， 涉及到共享變量及重要狀態(tài)修改的， 要加 INFO 日志。 改進(jìn)措施：在啟動(dòng)應(yīng)用或啟動(dòng)相應(yīng)配置時(shí)， 檢測(cè)所有的配置項(xiàng)， 打印相應(yīng)的INFO日志， 確保所有配置都加載成功。 原因十：業(yè)務(wù)不熟悉導(dǎo)致的錯(cuò)誤。 在中大型系統(tǒng)， 部分業(yè)務(wù)邏輯和業(yè)務(wù)交互都比較復(fù)雜， 整個(gè)的業(yè)務(wù)邏輯可能存在于多個(gè)開發(fā)同學(xué)的大腦里， 每個(gè)人的認(rèn)識(shí)都不是完整的。這很容易導(dǎo)致業(yè)務(wù)編碼錯(cuò)誤。 改進(jìn)措施：通過多人討論和溝通， 設(shè)計(jì)正確的業(yè)務(wù)用例， 根據(jù)業(yè)務(wù)用例來編寫和實(shí)現(xiàn)業(yè)務(wù)邏輯；最終的業(yè)務(wù)邏輯和業(yè)務(wù)用例必須完整存檔；在業(yè)務(wù)接口中注明該業(yè)務(wù)的前置條件、處理邏輯、后置校驗(yàn)和注意事項(xiàng)；當(dāng)業(yè)務(wù)變化時(shí)， 需要同步更新業(yè)務(wù)注釋；代碼REVIEW。業(yè)務(wù)注釋是業(yè)務(wù)接口的重要文檔， 對(duì)業(yè)務(wù)理解起著重要的緩存作用。 原因十一：設(shè)計(jì)問題導(dǎo)致的錯(cuò)誤。 比如同步串行方式會(huì)有性能、響應(yīng)慢的問題， 而并發(fā)異步方式可以解決性能、響應(yīng)慢的問題， 但會(huì)帶來安全、正確性的隱患。異步方式會(huì)導(dǎo)致編程模型的改變， 新增異步消息推送和接收等新的問題。使用緩存能夠提高性能， 但是又會(huì)存在緩存更新的問題。 改進(jìn)措施：編寫和仔細(xì)評(píng)審設(shè)計(jì)文檔。設(shè)計(jì)文檔必須闡述背景、需求、所滿足的業(yè)務(wù)目標(biāo)、要達(dá)到的業(yè)務(wù)性能指標(biāo)、可能的影響、設(shè)計(jì)總體思路、詳細(xì)方案、預(yù)見該方案的優(yōu)缺點(diǎn)及可能的影響；通過測(cè)試和驗(yàn)收， 確保改設(shè)計(jì)方案確實(shí)滿足業(yè)務(wù)目標(biāo)和業(yè)務(wù)性能指標(biāo)。 原因十二：未知細(xì)節(jié)問題導(dǎo)致的錯(cuò)誤。 比如緩沖區(qū)溢出、 SQL 注入攻擊。從功能上看是沒有問題的， 但是從惡意使用上看， 是存在漏洞的。再比如， 選擇 jackson 庫(kù)做 JSON 字符串解析， 默認(rèn)情況下， 當(dāng)對(duì)象新增字段時(shí)會(huì)導(dǎo)致解析出錯(cuò)。必須在對(duì)象上加 @JsonIgnoreProperties(ignoreUnknown = true) 注解才能正確應(yīng)對(duì)變化。如果選用其他 JSON 庫(kù)就不一定有這個(gè)問題。 改進(jìn)措施：一方面要通過經(jīng)驗(yàn)積累， 另一方面， 考慮安全問題和例外情況， 選擇成熟的經(jīng)過嚴(yán)格測(cè)試的庫(kù)。 原因十三：隨時(shí)間變化而出現(xiàn)的bug。 有些解決方案在過去看來是很不錯(cuò)的，但在當(dāng)前或者未來的情景中可能變得笨拙甚至不中用，也是常見的事情。比如像加密解密算法， 在過去可能認(rèn)為是完善的， 在破解之后就要慎重使用了。 改進(jìn)措施：關(guān)注變化以及漏洞修復(fù)消息，及時(shí)修正過時(shí)的代碼、庫(kù)、行為。 比如內(nèi)存泄露， 存儲(chǔ)空間不足， OutOfMemoryError 等。 改進(jìn)措施：增加對(duì)應(yīng)用系統(tǒng)的 CPU / 內(nèi)存 / 網(wǎng)絡(luò)等重要指標(biāo)的性能監(jiān)控。 系統(tǒng)出現(xiàn)的常見錯(cuò)誤： 1.實(shí)體在數(shù)據(jù)庫(kù)中的記錄不存在， 必須指明是哪個(gè)實(shí)體或?qū)嶓w標(biāo)識(shí)； 2.實(shí)體配置不正確， 必須指明是哪個(gè)配置有問題，正確的配置應(yīng)該是什么； 3.實(shí)體資源不滿足條件， 必須指明當(dāng)前資源是什么，資源要求是什么； 4.實(shí)體操作前置條件不滿足， 必須指明需要滿足什么前置條件，當(dāng)前的狀態(tài)是什么； 5.實(shí)體操作后置校驗(yàn)不滿足， 必須指明需要滿足什么后置校驗(yàn)， 當(dāng)前的狀態(tài)是什么； 6.性能問題導(dǎo)致超時(shí)， 必須指明是什么導(dǎo)致的性能問題，后續(xù)如何優(yōu)化； 7.多個(gè)子系統(tǒng)交互通信出錯(cuò)導(dǎo)致之間的狀態(tài)或數(shù)據(jù)不一致？ 一般難以定位的錯(cuò)誤會(huì)出現(xiàn)在比較底層的地方。因?yàn)榈讓訜o法預(yù)知具體的業(yè)務(wù)場(chǎng)景， 給出的錯(cuò)誤消息都是比較通用的。 這就要求在業(yè)務(wù)上層提供盡可能豐富的線索。錯(cuò)誤的產(chǎn)生一定是多個(gè)系統(tǒng)或?qū)哟谓换サ倪^程中在某一層棧上不滿足前置條件導(dǎo)致。在編程時(shí)， 在每一層棧中盡可能確保所有必須的前置條件滿足，盡可能避免錯(cuò)誤的參數(shù)傳遞到底層， 盡可能地將錯(cuò)誤截獲在業(yè)務(wù)層。 大多數(shù)錯(cuò)誤都是由多種原因組合產(chǎn)生。但每一種錯(cuò)誤必定有其原因。在解決錯(cuò)誤之后， 要深入分析錯(cuò)誤是如何發(fā)生的， 如何避免這些錯(cuò)誤再次發(fā)生。努力就能成功， 但是：反思才能進(jìn)步 ！ 1.盡可能完整。每一條錯(cuò)誤日志都完整描述了：什么場(chǎng)景下發(fā)生了什么錯(cuò)誤， 什么原因（或者哪些可能原因）， 如何解決（或解決提示）； 2.盡可能具體。比如 NC 資源不足， 究竟具體指什么資源不足， 是否可以通過程序直接指明；通用錯(cuò)誤，比如 VM NOT EXIST ， 要指明在什么場(chǎng)景下發(fā)生的，可能便于后續(xù)統(tǒng)計(jì)的工作。 3.盡可能直接。最理想的錯(cuò)誤日志應(yīng)該讓人在第一直覺下能夠知道是什么原因?qū)е?，該怎么去解決，而不是還要通過若干步驟去查找真正的原因。 4.將已有經(jīng)驗(yàn)集成直接到系統(tǒng)中。所有已經(jīng)解決過的問題及經(jīng)驗(yàn)都要盡可能以友好的方式集成到系統(tǒng)中，給新進(jìn)人員更好的提示，而不是埋藏在其他地方。 5.排版要整潔有序， 格式統(tǒng)一化規(guī)范化。密密麻麻、隨筆式的日志看著就揪心， 相當(dāng)不友好， 也不便于排查問題。 6.采用多個(gè)關(guān)鍵字唯一標(biāo)識(shí)請(qǐng)求，突出顯示關(guān)鍵字：時(shí)間、實(shí)體標(biāo)識(shí)（比如vmname）、操作名稱。 登錄到應(yīng)用服務(wù)器 -> 打開日志文件 -> 定位到錯(cuò)誤日志位置 -> 根據(jù)錯(cuò)誤日志的線索的指導(dǎo)去排查、確認(rèn)問題和解決問題。 1.從登陸到打開日志文件：由于應(yīng)用服務(wù)器有多臺(tái)， 要逐一登錄上去查看實(shí)在不方便。需要編寫一個(gè)工具放在 AG 上直接在 AG 上查看所有服務(wù)器日志， 甚至直接篩選出所需要的錯(cuò)誤日志。 2.定位錯(cuò)誤日志位置。目前日志的排版密密麻麻，不易定位到錯(cuò)誤日志。一般可以先采用"時(shí)間"來定位到錯(cuò)誤日志的附近前面的地方， 然后使用 實(shí)體關(guān)鍵字 / 操作名稱 組合來鎖定錯(cuò)誤日志地方。根據(jù) requestId 定位錯(cuò)誤日志雖然比較符合傳統(tǒng)，但是要先找到 requestId , 并且不具有描述性。最好能直接根據(jù)時(shí)間/內(nèi)容關(guān)鍵字來定位錯(cuò)誤日志位置。 3.分析錯(cuò)誤日志。錯(cuò)誤日志的內(nèi)容最好能夠更加直接明了， 能夠明確指明與當(dāng)前要排查的問題特征是吻合的， 并且給出重要線索。 通常， 程序錯(cuò)誤日志的問題就是日志內(nèi)容是針對(duì)當(dāng)前代碼情境才能理解，看上去簡(jiǎn)潔， 但總是寫的不全， 半英文格式；一旦離開代碼情境， 就很難知道究竟說的是什么， 非要讓人思考一下或者去看看代碼才能明白日志說的是什么含義。這不是自己給自己罪受？ if ((storageType == StorageType.dfs1 || storageType == StorageType.dfs2)else {"zone storage type not support, zone: " + zone.getZoneId() + ", storageType: " zone 要支持什么 storage type 才是正確的? Do Not Let Me Think ! 錯(cuò)誤日志應(yīng)該做到：即使離開代碼情境，也能清晰地描述發(fā)生了什么。 此外，如果能夠直接在錯(cuò)誤日志中說明清楚原因， 在做巡檢日志的時(shí)候也可以省些力氣。 從某種意義上來說， 錯(cuò)誤日志也可以是一種非常有益的文檔，記錄著各種不合法的運(yùn)行用例。 目前程序錯(cuò)誤日志的內(nèi)容可能存在如下問題： 1. 錯(cuò)誤日志沒有指明錯(cuò)誤參數(shù)和內(nèi)容： catch(Exception ex){"control ip insert failed" , ex);return new ResultSet<AddControlIpResponse>(
沒有指明插入失敗的 control ip. 如果加上 control ip 關(guān)鍵字， 更容易搜索和鎖定錯(cuò)誤。 log.error("Get some errors when insert subnet and its IPs into database. Add subnet or IP failure." , e);
沒有指明是哪個(gè) subnet 的它下屬的哪些 IP. 值得注意的是， 要指明這些要額外做一些事情， 可能會(huì)稍微影響性能。這時(shí)候需要權(quán)衡性能和可調(diào)試性。 解決方案：使用 String.format("Some msg to ErrorObj: %s", errobj) 方法指明錯(cuò)誤參數(shù)及內(nèi)容。 這通常要求對(duì) DO 對(duì)象編寫可讀的 toString 方法。 log.error("nc has exist, nc ip" + request.getIp()); 在 createNc 中檢測(cè)到 NC 已經(jīng)存在報(bào)錯(cuò)。但是日志上沒有指明錯(cuò)誤場(chǎng)景， 讓人猜測(cè)，為什么會(huì)報(bào)NC已存在錯(cuò)誤。 log.error("nc has exist when want to create nc, please check nc parameters. Given nc ip: " + request.getIp());"[create nc] nc has exist, please check nc parameters. Given nc ip: " + request.getIp());
log.error("not all vm destroyed, nc id " + request.getNcId());
log.error("[delete nc] some vms [%s] in the nc are not destroyed. nc id: %s" , vmNames, request.getNcId());
解決方案：錯(cuò)誤消息加上 when 字句， 或者錯(cuò)誤消息前加上 【接口名】, 指明錯(cuò)誤場(chǎng)景，直接從錯(cuò)誤日志就知道明白了。 一般能夠知道 executor 的可以加上 【接口名】， service 加上 when 字句。 if (aliMonitorReporter == null) {"aliMonitorReporter is null!" );else {
log.error("aliMonitorReporter is null, probably not initialized properly, please check configuration in file xxx." );
if (diskWbps == null && diskRbps == null && diskWiops == null && diskRiops == null) {"none of attribute is specified for modifying" );
log.error("[modify disk attribute] None of [diskWbps,diskRbps,diskWiops,diskRiops] is specified for disk id:" + diskId);
解決方案：更清晰貼切地描述錯(cuò)誤內(nèi)容。 4. 排查問題的引導(dǎo)內(nèi)容不明確： log.error("get gw group ip segment failed. zkPath: " + LockResource.getGwGroupIpSegmnetLockPath(request.getGwGroupId()));
zkPath ? 如何去排查這個(gè)問題？我該去找誰(shuí)？到哪里去查找更具體的線索？ 解決方案：加上相應(yīng)的背景知識(shí)和引導(dǎo)排查措施。 5. 錯(cuò)誤內(nèi)容不夠具體細(xì)致： if (!ncResourceService.isNcResourceEnough(ncResourceDO, vmResourceCondition)) {"disk space is not enough at vm's nc, nc id:" + vmDO.getNcId());
究竟是什么資源不夠？目前剩余多少？現(xiàn)在需要多少？值得注意的是， 要指明這些要額外做一些事情， 可能會(huì)稍微影響性能。這時(shí)候需要權(quán)衡性能和可調(diào)試性。 解決方案：通過改進(jìn)程序或程序技巧， 盡可能揭示出具體的差異所在， 減少人工比對(duì)的操作。 6. 半英文句式讀起來不夠清晰明白，需要思考來拼湊起完整的意思： log.warn("cache status conflict, device id " +deviceDO.getId()+" db status " +deviceDO.getStatus() +", nc status " + status);
log.warn(String.format("[query cache status] device cache status conflicts between regiondb and nc, status of device '%s' in regiondb is %s , but is %s in nc." , deviceDO.getId(), deviceDO.getStatus(), status));
總結(jié)起來， 錯(cuò)誤日志格式可以為： log.error("[接口名或操作名] [Some Error Msg] happens. [params] [Probably Because]. [Probably need to do]." );"[接口名或操作名] [Some Error Msg] happens. [%s]. [Probably Because]. [Probably need to do]." , params));
log.error("[Some Error Msg] happens to 錯(cuò)誤參數(shù)或內(nèi)容 when [in some condition]. [Probably Because]. [Probably need to do]." );"[Some Error Msg] happens to %s when [in some condition]. [Probably Because]. [Probably need to do]." , parameters));
[Probably Reason]. [Probably need to do]. 在某些情況下可以省略；在一些重要接口和場(chǎng)景下最好能說明一下。 每一條錯(cuò)誤日志都是獨(dú)立的，盡可能完整、具體、直接說明何種場(chǎng)景下發(fā)生了什么錯(cuò)誤，由什么原因?qū)е?，要采用什么措施或步驟。 Java 系列最新教程：https://github.com/javastacks/javastack 1.String.format 的性能會(huì)影響打日志嗎？一般來說， 錯(cuò)誤日志應(yīng)該是比較少的， 使用 String.format 的頻度并不會(huì)太高，不會(huì)對(duì)應(yīng)用和日志造成影響。 2.開發(fā)時(shí)間非常緊張時(shí)， 有時(shí)間去斟酌字句嗎？建立一個(gè)標(biāo)準(zhǔn)化的內(nèi)容格式，將內(nèi)容往格式套，可以節(jié)省斟酌字句的時(shí)間。 3.什么時(shí)候使用 info, warn , error ? info 用于打印程序應(yīng)該出現(xiàn)的正常狀態(tài)信息， 便于追蹤定位； warn 表明系統(tǒng)出現(xiàn)輕微的不合理但不影響運(yùn)行和使用； error 表明出現(xiàn)了系統(tǒng)錯(cuò)誤和異常，無法正常完成目標(biāo)操作。 http://stackoverflow.com/questions/2031163/when-to-use-log-level-warn-vs-error 錯(cuò)誤日志是排查問題的重要手段之一。當(dāng)我們編程實(shí)現(xiàn)一項(xiàng)功能時(shí)， 通常會(huì)考慮可能發(fā)生的各種錯(cuò)誤及相應(yīng)原因： 要排查出相應(yīng)的原因， 就需要一些關(guān)鍵描述來定位原因。這就會(huì)形成三元組： 錯(cuò)誤現(xiàn)象 -> 錯(cuò)誤關(guān)鍵描述 -> 最終的錯(cuò)誤原因。 需要針對(duì)每一種錯(cuò)誤盡可能提供相應(yīng)的錯(cuò)誤關(guān)鍵描述，從而定位到相應(yīng)的錯(cuò)誤原因。 也就是說，編程的時(shí)候，要仔細(xì)思考， 哪些描述是非常有利于定位錯(cuò)誤原因的， 盡可能將這些描述添加到錯(cuò)誤日志中。 文中沒有指出的問題或困難， 請(qǐng)?zhí)岢瞿愕慕ㄗh。 推薦閱讀：
字節(jié)跳動(dòng)涉代碼抄襲被訴陪22.74億，連錯(cuò)誤的函數(shù)都搬？
程序員必須清楚的 10 個(gè)高級(jí) SQL 概念！
最近面試BAT，整理一份面試資料《 Java面試BATJ通關(guān)手冊(cè) 》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫(kù)、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點(diǎn)個(gè)「 在看 」，點(diǎn)擊上方小卡片，進(jìn)入公眾號(hào)后 面試題 」領(lǐng)取，更多內(nèi)容陸續(xù)奉上。 朕已閱
