用 try...except...提高代码的稳定性，是否是好习惯？

[Leon6868]

把每个可能出错的东西都套上 try...except，这样有什么坏处吗？
比如,是否会影响代码的执行效率？

[xujiaze]

try except 还是很有必要的，但是不是万能的解决方案
同意其他人的回答，不要过度依赖

[bingmang]

go 就没这个烦恼

[movistar]

考虑好自己写的代码是不是核心关键逻辑,不是核心逻辑那就都加上 try catch/except
不要扩大影响面,比如有一个接口可能向下游拿十几个 RPC,你加了个功能,结果出异常,难道就 let it crash 让一个不是关键流程直接搞挂整个接口没有任何返回?
如果整条链路每个信息都很重要,那可以,没问题,let it crash 直接在线程顶层 try catch/except 不要让服务崩掉就可以了

否则建议全部都加上...

任何现代化的语言都不至于 catch 一下就不知道出错在哪,打个 ERROR Log,监控 ERROR Log 量,不要放任 ERROR 就行了

当然取决于你什么行业,什么方向,不同方向对于服务要求不同....

[ayavvv]

try catch 我一般最外层才加，要不然很多时候内层代码把异常吃掉了，再去翻日志很麻烦

[EscYezi]

没有必要全部加上。只有在不能对外直接抛出异常时才必须尝试捕获异常，比如返回响应给用户之前。大部分异常即使捕获了也处理不了，还不如速错；如果是能处理的则应该提前检测是否可能出错，而不是等抛异常了再进行处理。

[wzwwzw]

内部能处理的异常就 try 否则就抛给调用方。

[opengps]

根据需求选用，我最早入门时候，就是各种包裹才能实现出现故障不退出，因为我的 GPS 服务器需要长久存活才能不因为个别数据包错误中断

[xpresslink]

try...except...提高代码的稳定性
这个说法是存疑的，try...except..本身并不能提高代码的稳定性
如果用了 try 就要识别处理，识别和处理的水平决定代码的稳定性

比如你直接把异常直接弄成 Exception 完全没有细化，又不去有针对性处理，还不如直接报错还能知道为什么错了。
但是凡事都有代价，写得 try 越多无效率代码就会浪费越多。