做了這麼久的專案，在公司，不大不小的問題基本都能短期內解決或者提供方案，尤其給同事提供，也算是得心應手，可今天自己用一小時的時間買了個不爽。
也許在博友嚴重，這種低智商的錯誤不應該發生，但是卻發生在我這個智商不是太天才的人身上了。
儲存過程除錯：
code
1alter
procedure
[dbo].
[p_chkuserinfo]2
(3@deviceid
varchar(64
),4@rlt
tinyint
output5)
6as7begin
8declare
@cnt
asint
9declare
@flag
asint
10select
@cnt
=count(*
) from
userinfo
where
deviceid
=@deviceid;11
if(@cnt
>0)
12begin
13select
@flag
=valid
from
userinfo
where
deviceid
=@deviceid;14
if(@flag=0
)15begin
16set
@rlt=0
--已經註冊的
17end
18else
19begin
20set
@rlt=1
--未註冊
21end
22end
23else
24begin
25insert
into
userinfo(deviceid,valid)
values
(@deviceid,1
);26
set@rlt=3
--原來使用者表沒有的
27end
28end
如此簡單，乙個裝置沒有註冊，怎麼也註冊不上，返回值是3；
顯然是沒有插入資料啊，可沒有異常啊，不明白，半小時過去了， 問題依舊，出去溜達一圈吧，總不能這麼鬱悶著吧，不是吧，儲存過程有異常不會丟擲，除非你做了異常處理。
於是就在儲存過程中做了異常處理，問題一下子顯出來了，截斷了，暈倒，哦，對照一下，裝置的id超過了長度32位，應該64才夠用啊。
之前好好的程式，本地資料庫和開發的不同步了。
良好的專案管理，良好的程式設計風格需要我們時刻銘記在心，如果儲存過程做了異常處理，如果資料庫和開發庫同步，如果聰明點，意識到儲存過程會吃掉異常，如果再聰明點...... 我還會犯這個低階的錯誤嗎，下班了，不再懺悔了。
異常處理是設計的重要部分，不論何時何地，猶如事務一樣，也不要把多執行緒隨便拋到腦後。
陰溝裡翻船之C函式memset
服務端每次處理客戶端請求的執行實現發現已接近100毫秒左右，這尼瑪真不能忍。起初還懷疑是與memcache服務進行通訊上的問題，結果經過一步步打log輸出各個環節的呼叫時間，最終定位到了乙個c函式memset 占用了每次處理的99 的時間！每次在收到服務端的請求時都對乙個50m左右的資料執行了一次m...
精彩十年（2） 陰溝裡也翻船
按照常理，我的第 一 二兩本書都是在人郵出版的，而且是人郵最先向我約稿寫書的，後面的書自然就會在人郵出版，至少後面還會在人郵出版出幾本書，不會這麼快另選東家，因為我一向注重誠信合作，而不是喜新厭舊之輩。但是令所有讀者都感到意外的是，我自第三本書開始就沒有在人郵出版了。究其原因將在本文後面介紹。在出版...
精彩十年（2） 陰溝裡也翻船
按照常理，我的第 一 二兩本書都是在人郵出版的，而且是人郵最先向我約稿寫書的，後面的書自然就會在人郵出版，至少後面還會在人郵出版出幾本書，不會這麼快另選東家，因為我一向注重誠信合作，而不是喜新厭舊之輩。但是令所有讀者都感到意外的是，我自第三本書開始就沒有在人郵出版了。究其原因將在本文後面介紹。在出版...