这是一个创建于 1530 天前的主题，其中的信息可能已经有所发展或是发生改变。
让我的头疼一会儿~
 |
1
goodboy95 2020-09-07 17:17:30 +08:00
是有点头疼，以前我也这么干过，后来发现不太好调试就分行了。
|
 |
2
mercurylanded 2020-09-07 17:27:21 +08:00
不怎么看，又不是我负责的代码
|
 |
3
xuanbg 2020-09-07 17:31:50 +08:00
把异常吃掉！哈哈哈，这个操作可以有。
如果 level 是个可有可无的值，且这个参数值完全不可控的话，这样其实挺合适的。如果不是的话……造孽啊 |
 |
4
chendy 2020-09-07 18:03:48 +08:00
判断 null 是不可能判断的，一辈子都不会的
只能靠吃异常，才勉强会写点 crud |
 |
5
kop1989 2020-09-07 18:06:02 +08:00
如果 level 有默认值，且契合业务的话，应该也是合理的吧：
如果传过来的值不合法，就忽略，采用默认值。 |
|
6
kop1989 2020-09-07 18:07:36 +08:00
所以 C#有 TryParse(string,out int) return bool 这种语法糖。
|
 |
8
xuzheliang 2020-09-07 18:27:07 +08:00
这就是我会写的代码...不过这样写的问题在哪？一眼不就知道是什么意思了吗？（调试不方便除外）
|
 |
9
ThomasZ 2020-09-07 20:22:03 +08:00 via Android
@xuzheliang 问题他扑获的空指针异常啊。。。。 那个 level=l 那就傻了
|
 |
10
yeqizhang 2020-09-07 20:40:31 +08:00 via Android
借楼，改成三目运算符判断空怎样？
|
 |
11
hzw94 OP ---
图上的`try...catch`的根本原因是为了防止前端未提交`level`参数，导致后端无法获取对象，进而在执行`trim()`语法时抛出`null 异常`。 问题出在前端而不是后端，要保证前端参数正确，前端的锅不要丢给后端。 开发者意识到了问题，处理方法却是错误的。 --- 我最想讨论的是，`try...catch`的正确用法是什么？ 我懂的也不多，但至少有一点要遵循，任何情况下`catch`中要将异常打印到日志里面，方便开发者调试，提醒接盘侠有异常。 如果没有日志，在数百数千行代码定位一个隐形 bug，要命的！ |
|
12
xuzheliang 2020-09-08 21:15:47 +08:00
@ThomasZ 没想到问题在这...受教了
|
Select Language