blocks|key|1213123|text|解决这个问题的正确工具是单元测试。如果你有由真实代码引发的异常，而单元测试没有引发，那么你需要更多的单元测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1213124|考虑一下这个|1213125|def+f(duck):
++++try:
++++++++duck.quack()
++++except+???+could+be+anything|code-block|syntax|javascript|1213126|duck可以是任何对象|1213127|显然，如果鸭子没有叫声，你可以有一个AttributeError，如果鸭子有叫声，你可以有一个TypeError，但它是不可调用的。您不知道duck.quack()可能会产生什么，甚至可能是DuckError或其他什么|offset|length|style|CODE|1213128|现在假设你有这样的代码|1213129|arr[i]+=+get_something_from_database()|1213130|如果它引发了一个IndexError，你不知道它是来自arri还是来自数据库函数的内部。通常情况下，在哪里发生异常并不重要，而是发生了一些错误，没有发生您想要发生的事情。|1213131|一种方便的技术是捕获异常，也许还可以像下面这样重新处理异常|1213132|except+Exception+as+e
++++#inspect+e,+decide+what+to+do
++++raise|1213133|entityMap^0|0|0|0|0|I|E|1B|9|1Y|C|2N|9|0|0|0|8|A|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|14|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|15|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|16|8|@$M|17|N|18|O|P]|$M|19|N|1A|O|P]|$M|1B|N|1C|O|P]|$M|1D|N|1E|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1F|8|@]|9|@]|A|$]]|$1|S|3|T|5|F|7|1G|8|@]|9|@]|A|$G|H]]|$1|U|3|V|5|6|7|1H|8|@$M|1I|N|1J|O|P]]|9|@]|A|$]]|$1|W|3|X|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|F|7|1L|8|@]|9|@]|A|$G|H]]|$1|10|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|11|$]]

The correct tool to solve this problem is unittests. If you are having exceptions raised by real code that the unittests do not raise, then you need more unittests.

Consider this

<pre><code>def f(duck):
 try:
 duck.quack()
 except ??? could be anything
</code></pre>

duck can be any object

Obviously you can have an <code>AttributeError</code> if duck has no quack, a <code>TypeError</code> if duck has a quack but it is not callable. You have no idea what <code>duck.quack()</code> might raise though, maybe even a <code>DuckError</code> or something

Now supposing you have code like this

<pre><code>arr[i] = get_something_from_database()
</code></pre>

If it raises an <code>IndexError</code> you don't know whether it has come from arr[i] or from deep inside the database function. usually it doesn't matter so much where the exception occurred, rather that something went wrong and what you wanted to happen didn't happen.

A handy technique is to catch and maybe reraise the exception like this

<pre><code>except Exception as e
 #inspect e, decide what to do
 raise
</code></pre>

blocks|key|1213341|text|我在使用套接字的时候遇到了这个问题，我想找出我会遇到的所有错误条件(所以不是试图创建错误并找出是什么套接字，我只是想要一个简明的列表)。最终，我使用grep‘’ing+"/usr/lib64/python2.4/test/test_socket.py“来表示"raise"：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1213342|$+grep+raise+test_socket.py
Any+exceptions+raised+by+the+clients+during+their+tests
++++++++raise+TypeError,+"test_func+must+be+a+callable+function"
++++raise+NotImplementedError,+"clientSetUp+must+be+implemented."
++++def+raise_error(*args,+**kwargs):
++++++++raise+socket.error
++++def+raise_herror(*args,+**kwargs):
++++++++raise+socket.herror
++++def+raise_gaierror(*args,+**kwargs):
++++++++raise+socket.gaierror
++++self.failUnlessRaises(socket.error,+raise_error,
++++self.failUnlessRaises(socket.error,+raise_herror,
++++self.failUnlessRaises(socket.error,+raise_gaierror,
++++++++raise+socket.error
++++#+Check+that+setting+it+to+an+invalid+value+raises+ValueError
++++#+Check+that+setting+it+to+an+invalid+type+raises+TypeError
++++def+raise_timeout(*args,+**kwargs):
++++self.failUnlessRaises(socket.timeout,+raise_timeout,
++++def+raise_timeout(*args,+**kwargs):
++++self.failUnlessRaises(socket.timeout,+raise_timeout,|code-block|syntax|javascript|1213343|这是一个非常简洁的错误列表。当然，这只适用于具体情况，并取决于测试的准确性(通常是准确的)。否则，您需要捕获所有异常，记录它们，剖析它们，并弄清楚如何处理它们(这对于单元测试来说并不困难)。|1213344|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I ran into this when using socket, I wanted to find out all the error conditions I would run in to (so rather than trying to create errors and figure out what socket does I just wanted a concise list). Ultimately I ended up grep'ing "/usr/lib64/python2.4/test/test_socket.py" for "raise":

<pre><code>$ grep raise test_socket.py
Any exceptions raised by the clients during their tests
 raise TypeError, "test_func must be a callable function"
 raise NotImplementedError, "clientSetUp must be implemented."
 def raise_error(*args, **kwargs):
 raise socket.error
 def raise_herror(*args, **kwargs):
 raise socket.herror
 def raise_gaierror(*args, **kwargs):
 raise socket.gaierror
 self.failUnlessRaises(socket.error, raise_error,
 self.failUnlessRaises(socket.error, raise_herror,
 self.failUnlessRaises(socket.error, raise_gaierror,
 raise socket.error
 # Check that setting it to an invalid value raises ValueError
 # Check that setting it to an invalid type raises TypeError
 def raise_timeout(*args, **kwargs):
 self.failUnlessRaises(socket.timeout, raise_timeout,
 def raise_timeout(*args, **kwargs):
 self.failUnlessRaises(socket.timeout, raise_timeout,
</code></pre>

Which is a pretty concise list of errors. Now of course this only works on a case by case basis and depends on the tests being accurate (which they usually are). Otherwise you need to pretty much catch all exceptions, log them and dissect them and figure out how to handle them (which with unit testing wouldn't be to difficult).

blocks|key|1428057|text|我猜，由于缺乏静态类型规则，解决方案只能是不精确的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1428058|我不知道一些检查异常的工具，但你可以想出你自己的工具来满足你的需求(这是一个尝试静态分析的好机会)。|1428059|作为第一次尝试，您可以编写一个函数来构建一个AST，找到所有Raise节点，然后尝试找出引发异常的常见模式(例如，直接调用构造函数)|offset|length|style|CODE|1428060|假设x为以下程序：|1428061|x+=+'''\
if+f(x):
++++raise+IOError(errno.ENOENT,+'not+found')
else:
++++e+=+g(x)
++++raise+e
'''|code-block|syntax|javascript|1428062|使用compiler包构建AST：|1428063|tree+=+compiler.parse(x)|1428064|然后定义一个Raise访问者类：|1428065|class+RaiseVisitor(object):
++++def+__init__(self):
++++++++self.nodes+=+[]
++++def+visitRaise(self,+n):
++++++++self.nodes.append(n)|1428066|遍历AST采集Raise节点：|1428067|v+=+RaiseVisitor()
compiler.walk(tree,+v)

>>>+print+v.nodes
[
++++Raise(
++++++++CallFunc(
++++++++++++Name('IOError'),
++++++++++++[Getattr(Name('errno'),+'ENOENT'),+Const('not+found')],
++++++++++++None,+None),
++++++++None,+None),
++++Raise(Name('e'),+None,+None),
]|1428068|您可以继续使用编译器符号表解析符号，分析数据依赖关系等。或者您可能只是推断，CallFunc(Name('IOError'),+...)“绝对应该意味着提升IOError"，这对于快速的实际结果来说是很好的:)|1428069|entityMap^0|0|0|U|5|0|2|1|0|0|2|8|0|0|6|5|0|0|7|5|0|0|12|U|26|7|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|18|8|@$F|19|G|1A|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1B|8|@$F|1C|G|1D|H|I]]|9|@]|A|$]]|$1|L|3|M|5|N|7|1E|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|1F|8|@$F|1G|G|1H|H|I]]|9|@]|A|$]]|$1|S|3|T|5|N|7|1I|8|@]|9|@]|A|$O|P]]|$1|U|3|V|5|6|7|1J|8|@$F|1K|G|1L|H|I]]|9|@]|A|$]]|$1|W|3|X|5|N|7|1M|8|@]|9|@]|A|$O|P]]|$1|Y|3|Z|5|6|7|1N|8|@$F|1O|G|1P|H|I]]|9|@]|A|$]]|$1|10|3|11|5|N|7|1Q|8|@]|9|@]|A|$O|P]]|$1|12|3|13|5|6|7|1R|8|@$F|1S|G|1T|H|I]|$F|1U|G|1V|H|I]]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]]|15|$]]

I guess a solution could be only imprecise because of lack of static typing rules.

I'm not aware of some tool that checks exceptions, but you could come up with your own tool matching your needs (a good chance to play a little with static analysis).

As a first attempt, you could write a function that builds an AST, finds all <code>Raise</code> nodes, and then tries to figure out common patterns of raising exceptions (e. g. calling a constructor directly)

Let <code>x</code> be the following program:

<pre><code>x = '''\
if f(x):
 raise IOError(errno.ENOENT, 'not found')
else:
 e = g(x)
 raise e
'''
</code></pre>

Build the AST using the <code>compiler</code> package:

<pre><code>tree = compiler.parse(x)
</code></pre>

Then define a <code>Raise</code> visitor class:

<pre><code>class RaiseVisitor(object):
 def __init__(self):
 self.nodes = []
 def visitRaise(self, n):
 self.nodes.append(n)
</code></pre>

And walk the AST collecting <code>Raise</code> nodes:

<pre><code>v = RaiseVisitor()
compiler.walk(tree, v)

&gt;&gt;&gt; print v.nodes
[
 Raise(
 CallFunc(
 Name('IOError'),
 [Getattr(Name('errno'), 'ENOENT'), Const('not found')],
 None, None),
 None, None),
 Raise(Name('e'), None, None),
]
</code></pre>

You may continue by resolving symbols using compiler symbol tables, analyzing data dependencies, etc. Or you may just deduce, that <code>CallFunc(Name('IOError'), ...)</code> "should definitely mean raising <code>IOError</code>", which is quite OK for quick practical results :)

blocks|key|1213411|text|到目前为止，没有人解释为什么你不能有一个完整的，100%25正确的异常列表，所以我认为这是值得评论的。其中一个原因是函数是一流的。假设你有一个这样的函数：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1213412|def+apl(f,arg):
+++return+f(arg)|code-block|syntax|javascript|1213413|现在，apl可以引发f引发的任何异常。虽然在core库中没有太多类似的函数，但任何使用列表理解和自定义过滤器、map、reduce等的函数都会受到影响。|offset|length|style|CODE|1213414|文档和源代码分析器是这里唯一“严肃”的信息来源。只要记住他们不能做的事情。|1213415|entityMap^0|0|0|3|3|A|1|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]|$I|V|J|W|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

Noone explained so far, why you can't have a full, 100% correct list of exceptions, so I thought it's worth commenting on. One of the reasons is a first-class function. Let's say that you have a function like this:

<pre><code>def apl(f,arg):
 return f(arg)
</code></pre>

Now <code>apl</code> can raise any exception that <code>f</code> raises. While there are not many functions like that in the core library, anything that uses list comprehension with custom filters, map, reduce, etc. are affected.

The documentation and the source analysers are the only "serious" sources of information here. Just keep in mind what they cannot do.

blocks|key|1213462|text|我发现有两种方法可以提供信息。第一个是在iPython中运行代码，它将显示异常类型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1213463|n+=+2
str+=+'me+'
str+%2B+2
TypeError:+unsupported+operand+type(s)+for+%2B:+'int'+and+'str'|code-block|syntax|javascript|1213464|在第二种方式中，我们满足于捕获过多的内容，并随着时间的推移不断改进。在代码中包含一个try表达式并捕获except+Exception+as+err。打印足够的数据以了解抛出了什么异常。当抛出异常时，可以通过添加更精确的except子句来改进代码。当你觉得你已经捕获了所有相关的异常时，删除所有包含的异常。不管怎么说，这都是一件好事，因为它可以容忍编程错误。|offset|length|style|CODE|1213465|try:
+++so+something
except+Exception+as+err:
+++print+"Some+message"
+++print+err.__class__
+++print+err
+++exit(1)|1213466|entityMap^0|0|0|16|3|1F|N|32|6|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]|$I|V|J|W|K|L]|$I|X|J|Y|K|L]]|9|@]|A|$]]|$1|M|3|N|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|O|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|P|$]]

There are two ways that I found informative. The first one, run the code in iPython, which will display the exception type.
<pre><code>n = 2
str = 'me '
str + 2
TypeError: unsupported operand type(s) for +: 'int' and 'str'
</code></pre>
In the second way we settle for catching too much and improve on it over time. Include a <code>try</code> expression in your code and catch <code>except Exception as err</code>. Print sufficient data to know what exception was thrown. As exceptions are thrown improve your code by adding a more precise <code>except</code> clause. When you feel that you have caught all relevant exceptions remove the all inclusive one. A good thing to do anyway because it swallows programming errors.
<pre><code>try:
 so something
except Exception as err:
 print &quot;Some message&quot;
 print err.__class__
 print err
 exit(1)
</code></pre>

Is there a way knowing (at coding time) which exceptions to expect when executing python code?
I end up catching the base Exception class 90% of the time since I don't know which exception type might be thrown (reading the documentation doesn't always help, since many times an exception can be propagated from the deep. And many times the documentation is not updated or correct).
Is there some kind of tool to check this (like by reading the Python code and libs)?

How can I know which exceptions might be thrown from a method call?

有没有办法(在编码时)知道在执行python代码时会出现哪些异常？因为我不知道可能抛出哪种异常类型(阅读文档并不总是有帮助，因为很多时候可以从深层传播异常)，所以我最终捕获了基本异常类90%的时间。并且很多时候文档没有更新或不正确)。有没有某种工具可以检查这一点(比如通过读取Python代码和库)？

问如何知道方法调用中可能抛出哪些异常？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何知道方法调用中可能抛出哪些异常？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何知道方法调用中可能抛出哪些异常？
EN