資訊專欄INFORMATION COLUMN
摘要：編碼習慣之異常處理常識對于透傳云系統或者是其他的大型系統，最怕的事情第一是系統出現了異常我不知道，等問題鬧大了用戶投訴了才知道出問題了。隨著透傳云業務流程越來越復雜，和周邊子模塊一堆集成，一堆的后臺隊列任務，任何一塊都可能出問題。
編碼習慣之異常處理
@(常識)
對于 透傳云 系統或者是其他的大型IT系統，最怕的事情
第一是系統出現了異常我不知道，等問題鬧大了用戶投訴了才知道出問題了。
第二就是出了問題之后無法找到出錯原因。
針對這2個問題，說說我對異常是怎么樣想的和規定異常處理的。
第一個問題，系統出異常了我不知道，等技術支持問的時候才知道。
這個問題出現非常多，而且非常嚴重。經常會出現用戶反饋、投訴過來說某個功能不可用，技術支持找的時候開發人員再定位分析之后，才發現之前的某一步出錯了。隨著 透傳云 業務流程越來越復雜，和周邊子模塊一堆集成，一堆的后臺隊列任務，任何一塊都可能出問題。
舉幾個例子：
技術支持：呀，透傳云又傳不了數據了？NB模塊下發命令又發不下去了？設備怎么添加失敗啊？
開發人員：好，我查一查。
開發人員A：哎哎哎，世超你看看看 API 是不是獲取數據有問題啊，志遠NB服務器是不是停了啊。。。。。
針對某些業務，在流程上當然可以采取相對的策略來保證，但從開發的角度來說，任何規定都無法保證一定不會發生錯誤，老虎也有打盹的時候，我只相信代碼。
代碼方面：
沒事不要亂try catch 尤其是 API 異常都拋出來怎么了 一個e.getMessage包裝到data數據區再加個錯誤碼怎么了？ 直接拋到最上層用統一的全局異常處理去處理，里面做機制比如說：郵件或微信推送到開發組長和開發人員那里。（尤其是后臺隊列之類的操作）
新手最容易犯的錯誤，到處捕獲異常，到處加空判斷，自以為寫出了“健壯”的代碼，實際上完全相反。導致的問題，第一代碼可讀性很差，你如果工作了看到一半代碼是try-catch和空判斷你會同意我的觀點的，第二更加重要的掩蓋了很多錯誤，日志是不會有人看的，我們的目的是盡早讓錯誤拋出來。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/69095.html
摘要：對變量對象或者函數等進行命名時，選擇能清晰表達其用途的名字。其實，測試方法名應該明確指出測試的內容與條件。和這種命名方式是時代的前朝遺物。使用自己的異常類型筆者又一次錯誤地認為這一開發習慣是業內的共識。 作為 Java 開發人員，我們會遵循一系列的編碼風格和開發習慣。習慣使然是一方面，另一方面，我們也從不停下腳步質疑這些習慣。一段時間以后，筆者養成了一些不同于常人的編碼風格和開發習慣。...
摘要：比如面向連接的功能包發送接收數量包發送接收速率錯誤計數連接重連次數調用延遲連接狀態等。你要處理的，就是心跳超時的邏輯，比如延遲重連。發生異常后，可以根據不同的類型選擇斷線重連比如一些二進制協議的編解碼紊亂問題，或者調度到其他節點。 在java界，netty無疑是開發網絡應用的拿手菜。你不需要太多關注復雜的nio模型和底層網絡的細節，使用其豐富的接口，可以很容易的實現復雜的通訊功能。 和...
摘要：比如面向連接的功能包發送接收數量包發送接收速率錯誤計數連接重連次數調用延遲連接狀態等。你要處理的，就是心跳超時的邏輯，比如延遲重連。發生異常后，可以根據不同的類型選擇斷線重連比如一些二進制協議的編解碼紊亂問題，或者調度到其他節點。 在java界，netty無疑是開發網絡應用的拿手菜。你不需要太多關注復雜的nio模型和底層網絡的細節，使用其豐富的接口，可以很容易的實現復雜的通訊功能。 和...
摘要：文件中的代碼塊可用以下代碼塊包裹，以減少全局污染。命名規則原則盡量避免潛在命名沖突，避免過于精簡，應見名知意。必須與共同使用的構造函數名應以大寫字母開頭。變量所有的變量必須在使用前進行聲明。僅在函數和構造器內使，以明確的上下指向。 代碼格式規范 1.html中外部腳本引入盡量放在尾部。 2.一個html文件中只寫一個代碼塊。 3.JS文件中的代碼塊可用以下代碼塊包裹，以減少全局污染。 ...
閱讀 2312·2021-09-26 10:21
閱讀 2785·2021-09-08 09:36
閱讀 3065·2019-08-30 15:56
閱讀 954·2019-08-30 12:57
閱讀 916·2019-08-26 10:39
閱讀 3554·2019-08-23 18:11
閱讀 3077·2019-08-23 17:12
閱讀 1070·2019-08-23 12:18
