異常一定要處理，不能捕獲以後，之列印出來什麼都不管。比如某個業務層的方法中，對乙個異常做了捕獲，catch塊僅僅是列印出了異常，這種情況下異常是不容易被發現的，也就是異常被吞掉了
如果這個時候上層方法有事務註解，甚至會和spring的事務衝突
專案中異常的幾個注意事項
空指標是乙個很常見的異常了
這裡也引入我的兩個筆記供參考
處理空值的幾種標準做法
stream高階之optional
這就是契約式程式設計的重要性了，錯誤碼的規範在業界也是乙個統一的標準
其實還是方法的單一性職責
電腦科學領域的任何問題都可以通過增加乙個間接的中間層來解決，直接使用日誌系統的話，日誌系統與系統本身的耦合度太高了，所以加個中間層來解耦是乙個最佳方式。
測試或者生產的系統，日誌最好根據一定的格式來輸出，比如按天按時間點等，以便問題的排查
乙個細節點吧，介面中輸出日誌還是要注意的
log4j的日誌級別
這裡假設我們pro環境日誌級別是info，dev是debug，那麼**中必然會包含logger.debug的**，如果這部分**到了生產，它確實不會列印出來，但是如果引數有字串拼接或者引數有物件等，還是會執行的，浪費了系統資源。這種情況，就可以把debug的列印語句前加個判斷
生產不幸遇到過這樣的問題，就是日誌積累的量太多了
阿里巴巴編碼規約學習之安全規約
乙個成熟的系統都是要專門的鑑權機制的，比如微服務中的鑑權元件，或者單體應用中的 也可以起到類似的作用，市面上的鑑權手段多樣，這裡主要是說明許可權控制的重要性。在設計的時候，就要考慮到如果有別有用心的使用者，得到了其他使用者的訪問請求，加以修改，如果沒有許可權控制的話，是容易出大事的 手機號 身份證號...
阿里巴巴編碼規約學習之MYSQL資料庫
這個怎麼說呢，其實也有用y和n的，甚至有用success的，感覺有點亂，有個統一的標準還是好事，起碼乙個產品或者乙個系列的東西應該在這一點上是統一的 雖然說這個大小寫敏感的配置是可以修改的，但還是統一小寫比較好，不像oracle 注意有些 複數 表名其實是單詞的本義，並不是複數 之前也有用欄位名 u...
阿里巴巴開發規約之命名風格
我下邊總結的只是我自己平時需要注意的 1.userdo而不是userdo 2.方法名，成員變數名，區域性變數名，引數名統一用lowercamelcase駝峰標識 3.常量全部大寫用下劃線隔開，並且力求語意完整，不論多長，4.boolean型別的常量不要加是字首，否則容易引起框架異常，5.為了 自解釋...