对于这种操作，各位有什么看法？

[hzw94]

让我的头疼一会儿~

[goodboy95]

是有点头疼，以前我也这么干过，后来发现不太好调试就分行了。

[mercurylanded]

不怎么看，又不是我负责的代码

[xuanbg]

把异常吃掉！哈哈哈，这个操作可以有。

如果 level 是个可有可无的值，且这个参数值完全不可控的话，这样其实挺合适的。如果不是的话……造孽啊

[chendy]

判断 null 是不可能判断的，一辈子都不会的
只能靠吃异常，才勉强会写点 crud

[kop1989]

如果 level 有默认值，且契合业务的话，应该也是合理的吧：
如果传过来的值不合法，就忽略，采用默认值。

[kop1989]

所以 C#有 TryParse(string,out int) return bool 这种语法糖。

[kop1989]

@kop1989 #5 哦，抱歉，他只捕捉了空指针，这个我服……

[xuzheliang]

这就是我会写的代码...不过这样写的问题在哪？一眼不就知道是什么意思了吗？（调试不方便除外）

[ThomasZ]

@xuzheliang 问题他扑获的空指针异常啊。。。。 那个 level=l 那就傻了

[yungo8]

借楼，改成三目运算符判断空怎样？

[hzw94]

---

图上的`try...catch`的根本原因是为了防止前端未提交`level`参数，导致后端无法获取对象，进而在执行`trim()`语法时抛出`null 异常`。

问题出在前端而不是后端，要保证前端参数正确，前端的锅不要丢给后端。

开发者意识到了问题，处理方法却是错误的。

---

我最想讨论的是，`try...catch`的正确用法是什么？

我懂的也不多，但至少有一点要遵循，任何情况下`catch`中要将异常打印到日志里面，方便开发者调试，提醒接盘侠有异常。

如果没有日志，在数百数千行代码定位一个隐形 bug，要命的！

[xuzheliang]

@ThomasZ 没想到问题在这...受教了