首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 开发语言 > perl python >

teamleader要求小弟我把整个python工程里所有的try except去掉,改由最外部捕获,这样对吗

2013-01-05 
teamleader要求我把整个python工程里所有的try except去掉,改由最外部捕获,这样对吗?如题,leader要求我把

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的文本处理还是可以的!

[解决办法]

引用:
...
3.集中处理,一样可以很容易的找到出错的位置,你可以去看看Exception 的__traceback__ 中的Frame。你甚至还能够在集中处理中自动的打开异常文件,并定位到出现异常的行,只用几行代码就可以的。如果你分开处理异常的话,就没有这么方便了

意见很不错,经常看见用traceback模块在外进行捕获...

[解决办法]
你的程序,
1.要保证最外层能捕获错误,不要因为一个错误而引起整个服务的崩溃
2.不要让错误沉默,只要是错误,就应该抛出,只要是错误,就应该修复,修复不能用try,这是掩盖错误。

举例:

a = a/b

如果b为0,会有除0错误,最差的解决方法:

try
 a = a/b
catch 除0错误
 。。。

好一点的

if b!=0:
 a = a/b
else:
 a = 0

最好的办法:

分析需求,如果需求上b就是不可能为0的,那么错误就不在这里,而是在把0当b传入的地方,只有这样才能找到问题的根源。如果b是允许为0的,那么后续对应的操作是什么?很多时候,有缺陷的不一定是代码,而是设计,代码要把这些问题都极早暴露出来,而不是掩藏。

因此在这里放入try块是完全没有必要的,你的经理是对的。

热点排行