良好的项目管理,良好的编程风格需要我们时刻铭记在心,如果存储过程做了异常处理,如果数据库和开发库同步,如果聪明点,意识到存储过程会吃掉异常,如果再聪明点...... 你就不会犯这个低级的错误
做了这么久的项目,在公司,不大不小的问题基本都能短期内解决或者提供方案,尤其给同事提供,也算是得心应手,可今天自己用一小时的时间买了个不爽。
也许在博友严重,这种低智商的错误不应该发生,但是却发生在我这个智商不是太天才的人身上了。
存储过程调试:
Code
1 ALTER PROCEDURE [dbo].[P_ChkUserInfo]
2 (
3 @DeviceID varchar(64),
4 @Rlt tinyint output
5 )
6 AS
7 Begin
8 Declare @Cnt as int
9 Declare @Flag as int
10 Select @Cnt = count(*) from UserInfo where DeviceID=@DeviceID;
11 If (@Cnt>0)
12 Begin
13 Select @Flag = Valid from UserInfo where DeviceID=@DeviceID;
14 If(@Flag=0)
15 Begin
16 Set @Rlt =0 --已经注册的
17 End
18 Else
19 Begin
20 Set @Rlt=1 --未注册
21 End
22 End
23 Else
24 Begin
25 Insert into UserInfo(DeviceID,Valid) values(@DeviceID,1);
26 Set @Rlt = 3 --原来用户表没有的
27 End
28 End
如此简单,一个设备没有注册,怎么也注册不上,返回值是3;
显然是没有插入数据啊,可没有异常啊,不明白,半小时过去了, 问题依旧,出去溜达一圈吧,总不能这么郁闷着吧,不是吧,存储过程有异常不会抛出,除非你做了异常处理。
于是就在存储过程中做了异常处理,问题一下子显出来了,截断了,晕倒,哦,对照一下,设备的ID超过了长度32位,应该64才够用啊。
之前好好的程序,本地数据库和开发的不同步了。
良好的项目管理,良好的编程风格需要我们时刻铭记在心,如果存储过程做了异常处理,如果数据库和开发库同步,如果聪明点,意识到存储过程会吃掉异常,如果再聪明点...... 我还会犯这个低级的错误吗,下班了,不再忏悔了。
异常处理是设计的重要部分,不论何时何地,犹如事务一样,也不要把多线程随便抛到脑后。