今年有個目標之一就是提公升團隊**的質量，所以時常會思索如何把這件事做到更好，不想教條主義，也不想搞出乙個**規範，強制團隊照著做，落地的效果不好，反而把大家的積極性給弄沒了。所以我的原則是，我們一起看看什麼事是我們不能做的，排除掉，剩下的就是我們可以做的，同時真正搞清楚問題在**，而不是簡單的模仿。從我個人的經驗看，**優化中最重要的一點就是對異常情況的處理。今天，我就借這個話題，談談如何來優化我們的**。
坑1：捕捉異常不做處理
如下段**所示，不知道各位在自家的**中見過多少，我是期望大家不要遇見。且不說printstacktrace()這樣的**就不應該出線在正式的上線**中，不做處理本身這會導致業務的潛在問題被隱藏了，所以這個坑是我認為異常處理中最糟糕的一點。
trycatch(exception ex)
catch (filenotfoundexception e){
// alert that the specified file
// does not exist
catch (eofexception e){
// alert that the end of the file
// was reached
catch (objectstreamexception e){
// alert that the file is corrupted
catch (ioexception e){
// alert that some other i/o
// error occurred
坑4：將大段**放進乙個try-catch中
有時可以看到，一些**的作者恨不得把整個函式裡的實現**都放入單個try中，原因就在於為了圖省事，不願花時間分析一大塊**中哪幾行**會丟擲什麼異常、異常的具體型別是什麼，應該如何處理。這樣的做法導致異常發生後，後續除錯找問題更麻煩，一大段**中有太多的地方可能丟擲exception。這樣的做法導致，很難去統計和判斷要catch哪一些型別的exception, 只能寫乙個粗糙的exception, 又掉進我們說的第3個坑里。
一點總結
1. 出了什麼錯?2. 在哪齣的錯?
3. 為什麼出錯?
處理資料（文字）時遇到過的坑
訓練詞向量時，本來就是準備好格式一定訓練文字，然後呼叫gensim開始訓練。但是訓練過程中出現了這樣的么蛾子，編碼坑 unicodedecodeerror utf8 codec can t decode bytes in position 4229 4231 invalid continuation...
集合刪除元素那些年我們遇到過的坑
在專案中，資料封裝最多的就是使用集合，然後邏輯中對資料進行增加 更新 刪除動作 剛入行的童鞋，容易踩坑的地方是對集合刪除資料這一塊，對集合刪除我們可以用集合 自帶的迭代器進行刪除，或者用寫 的方式去刪除 另外乙個容易入坑的地方是對集合的迭代 wtcollection axlcoll2 axlhelp...
微信支付遇到過的坑
首先先來看下圖 流程如下 後台獲取訂單資訊，生成簽名 簽名必須按照簽名規範，請參照 qq簽名前字串如下 注意 用md5加密後將字母轉為大寫 3.將簽名引數和生成的簽名轉為xml格式，如下 jsapi支付測試body 10000100mch id 1add1a30ac87aa2db72f57a2375...