teamleader要求我把整个python工程里所有的try except去掉,改由最外部捕获,这样对吗?
如题,leader要求我把整个python工程里所有有try块而且except中直接pass或者返回错误的地方,把try块去掉,所最外层已经有一个try块了,可以捕获所有异常。我怎么老是感觉这样做欠妥当。。。。我的想法是:
1.工程中的所有函数都应该是API,这些API即使传入错误的参数,也应该正常返回,并且给出错误信息,供调用者判断。如果传入的 参数不对,直接崩溃了,调用者也是丈二和尚摸不着头脑。
2.在最外层捕获所有的异常不是明智之举,这将增加定位错误的时间和精力。
你们怎么看呢??
[解决办法]
这里有一个界面(不是GUI)的问题,就是用户代码和服务代码的错误传递方式的问题。
首先确定用异常还是错误返回值,他们是用户代码与服务代码之间的两种不同的处理错误的方式。
如果使用异常,我们应该保持一直,均为异常报错,如果,你的函数中发现参数错误,你要做的是抛出一个异常,对于你调用的其他函数,如果可能抛出异常,你有两个选择,1、捕获异常,然后再抛出一个你经过处理的异常,也或者不处理,转而抛出;2、不处理,任由他抛出,就像你抛出的一样。
你的问题,主要是出在是否应该捕获其他人抛出的异常上。
[解决办法]
学习一下,对Python的异常代价什么的不太清楚,但我觉得对于逻辑上较小的模块模块内直接抛出异常由模块外来处理是可以的。
[解决办法]
leader没有给你解释原因吗? 我替他解释一下吧!可能解释的不对
1.如果异常的数量少于20个,在哪里处理没有多大区别,如果有100个,就不一样了
2.如果except什么也不做,仅仅是pass,那为什么还用try呢?return erron_code是C语言的处理方式,不应该用在面向对象的技术里面,难道你想要每次调用一个函数,都得写一个if(func_return_ok)吗?
3.集中处理,一样可以很容易的找到出错的位置,你可以去看看Exception 的__traceback__ 中的Frame。你甚至还能够在集中处理中自动的打开异常文件,并定位到出现异常的行,只用几行代码就可以的。如果你分开处理异常的话,就没有这么方便了!
4.所以说,你们的leader应该是正确的。为什么你不用python写一个小脚本自动的移除try except呢?python的文本处理还是可以的!
[解决办法]