这是一个创建于 1939 天前的主题，其中的信息可能已经有所发展或是发生改变。
让我的头疼一会儿~
 | 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