pylint 警告“除了异常:”

发布于 2024-07-16 22:37:33 字数 143 浏览 7 评论 0原文

对于这样的块:

try:
    #some stuff
except Exception:
    pass

pylint 会引发警告 W0703 'Catch“Exception”'。 为什么?

For a block like this:

try:
    #some stuff
except Exception:
    pass

pylint raises warning W0703 'Catch "Exception"'. Why?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

溺深海 2024-07-23 22:37:34

因为它认为你捕获的太多了。 这是对的。

because it thinks that you're catching too much. and it's right.

木有鱼丸 2024-07-23 22:37:34

当某些事情......异常发生时,就会引发异常。 程序终止通常是一件好事。

您可能想忽略一些异常,但在我看来,没有充分的理由捕获这样的基类。

Exception are raised when something... exceptional occurs. It's generally a good thing that the program terminates.

You may want to ignore some exceptions, but IMO there's no good reason for catching a base-class like that.

终陌 2024-07-23 22:37:34

就像格雷格的回答一样,“Exception”是一个基类,异常应该从这个类派生,另请参见 异常。异常

这里有一个非常有用的 pydocs< 中的错误列表/b>

另请注意非常方便的回溯模块,它允许您找出异常发生的位置。 仅使用“ except: ...”将向您显示在您的情况下最应该使用的错误。 例如,尝试这个代码(切换注释),也许你会接受它:

import traceback
#absent = 'nothing'
try:
    something = absent
except  NameError:
    traceback.print_exc()
else:
    print("you get here only when you uncomment 'absent'") 

like Greg's answer, 'Exception' is a base class and exceptions should be derived from this class, see also exceptions.Exception.

Here a very usefull list of Errors in pydocs

Note also the very handy traceback module which allows you to find out where the exception occured. Using only 'except: ...' will show you what Error you should best use in your case. For example, try this code (toggle the comment), perhaps you'll accept it:

import traceback
#absent = 'nothing'
try:
    something = absent
except  NameError:
    traceback.print_exc()
else:
    print("you get here only when you uncomment 'absent'") 
爱你不解释 2024-07-23 22:37:34

捕获异常(不重新引发)有两个非常糟糕的副作用:错误被吃掉,因此您丢失了堆栈跟踪,而且 ctrl-c (或操作系统上的任何中断键)也会在这里处理。

此类程序的典型行为是它们无法停止,或者 ctrl-c 导致控制流向前跳(到异常处理程序),然后继续。 那么要么代码不能被中断,要么你需要敲击 ctrl-c 来让它停止。

Catching Exception (without re-raising) has 2 really bad side effects: errors get eaten, so you lose the stack trace, but also that ctrl-c (or whatever the break key is on your operating system) also gets handled here.

The typical behavior of programs like this is that either they can't be stopped, or that ctrl-c causes the control flow to skip forward (to the exception handler), and then continue. Then either the code can't be interrupted, or you need to hammer on ctrl-c to get it to stop.

鹊巢 2024-07-23 22:37:33

通常不捕获根 Exception 对象,而不是捕获更具体的对象 - 例如 IOException,这被认为是一种很好的做法。

考虑是否发生内存不足异常 - 简单地使用“pass”并不会让您的程序处于良好状态。

几乎唯一应该捕获异常的时间是在程序的顶层,您可以(尝试)记录它,显示错误,然后尽可能优雅地退出。

It's considered good practice to not normally catch the root Exception object, instead of catching more specific ones - for example IOException.

Consider if an out of memory exception occurred - simply using "pass" isn't going to leave your programme in a good state.

Pretty much the only time you should catch Exception is at the top level of your programme, where you can (try to) log it, display an error, and exit as gracefully as you can.

等往事风中吹 2024-07-23 22:37:33

最好只捕获非常窄范围的类型。 “异常”太笼统了 - 您最终不仅会捕获您计划的错误,还会捕获其他错误,这可能会掩盖代码中的错误,如果根本没有捕获它们,或者可能会捕获它们,则可以更快地诊断它们由单个非常高级的异常处理程序可以更好地处理。

话虽如此,从Python2.6开始,捕获Exception已经变得更加合理了,因为所有你不想捕获的异常(SystemExit、KeyboardInterrupt)不再继承自Exception。 相反,它们继承自通用的 BaseException。 这是故意这样做的,以便使捕获异常相对无害,因为它是一种常见的习惯用法。

有关详细信息和信息,请参阅 PEP 3110 未来的计划。

It's good practice to catch only a very narrow range of types. 'Exception' is too general - you will end up catching not just the errors you planned for, but other errors too, which may mask bugs in your code that would be quicker to diagnose if they weren't caught at all, or possibly would be better dealt with by a single very high level exception handler.

Having said that, since Python2.6, catching Exception has become a lot more reasonable, because all the exceptions that you wouldn't want to catch (SystemExit, KeyboardInterrupt) no longer inherit from Exception. They instead inherit from a common BaseException instead. This has been done deliberately in order to make catching Exception relatively harmless, since it is such a common idiom.

See PEP 3110 for details & future plans.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文