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