blocks|key|44169|text|Python并不认同异常应该只在异常情况下使用的想法，事实上，这种习惯用法是'ask+for+forgiveness,+not+permission'。这意味着使用异常作为流程控制的常规部分是完全可以接受的，并且实际上是鼓励的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|44170|这通常是一件好事，因为以这种方式工作有助于避免一些问题(作为一个明显的例子，竞争条件通常被避免)，并且它倾向于使代码更具可读性。|44171|假设你有这样一种情况，你接受了一些需要处理的用户输入，但却有一个已经处理过的默认值。try:+...+except:+...+else:+...结构使得代码的可读性非常好：|style|CODE|44172|try:
+++raw_value+=+int(input())
except+ValueError:
+++value+=+some_processed_value
else:+#+no+error+occured
+++value+=+process_value(raw_value)|code-block|syntax|javascript|44173|与它在其他语言中的工作方式进行比较：|44174|raw_value+=+input()
if+valid_number(raw_value):
++++value+=+process_value(int(raw_value))
else:
++++value+=+some_processed_value|44175|注意它的优点。不需要检查值是否有效并单独解析它，它们只需完成一次。代码也遵循更符合逻辑的顺序，主代码路径是第一个，然后是“如果它不工作，执行此操作”。|44176|这个例子自然有点做作，但它显示了这种结构的用例。|44177|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.python.org/2/glossary.html#term-eafp^0|12|11|0|0|0|16|U|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|19|8|@$A|1A|B|1B|H|I]]|9|@]|C|$]]|$1|J|3|K|5|L|7|1C|8|@]|9|@]|C|$M|N]]|$1|O|3|P|5|6|7|1D|8|@]|9|@]|C|$]]|$1|Q|3|R|5|L|7|1E|8|@]|9|@]|C|$M|N]]|$1|S|3|T|5|6|7|1F|8|@]|9|@]|C|$]]|$1|U|3|V|5|6|7|1G|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|1H|8|@]|9|@]|C|$]]]|X|$Y|$5|Z|10|11|C|$12|13]]]]

Python doesn't subscribe to the idea that exceptions should only be used for exceptional cases, in fact the idiom is <a href="http://docs.python.org/2/glossary.html#term-eafp" rel="noreferrer">'ask for forgiveness, not permission'</a>. This means that using exceptions as a routine part of your flow control is perfectly acceptable, and in fact, encouraged.

This is generally a good thing, as working this way helps avoid some issues (as an obvious example, race conditions are often avoided), and it tends to make code a little more readable.

Imagine you have a situation where you take some user input which needs to be processed, but have a default which is already processed. The <code>try: ... except: ... else: ...</code> structure makes for very readable code:

<pre><code>try:
 raw_value = int(input())
except ValueError:
 value = some_processed_value
else: # no error occured
 value = process_value(raw_value)
</code></pre>

Compare to how it might work in other languages:

<pre><code>raw_value = input()
if valid_number(raw_value):
 value = process_value(int(raw_value))
else:
 value = some_processed_value
</code></pre>

Note the advantages. There is no need to check the value is valid and parse it separately, they are done once. The code also follows a more logical progression, the main code path is first, followed by 'if it doesn't work, do this'.

The example is naturally a little contrived, but it shows there are cases for this structure.

blocks|key|2520058|text|在使用finally块时应该小心，因为它与在try中使用else块不是一回事，除了。不管try的结果如何，finally块都将运行，除非。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2520059|In+[10]:+dict_+=+{"a":+1}

In+[11]:+try:
+++....:+++++dict_["b"]
+++....:+except+KeyError:
+++....:+++++pass
+++....:+finally:
+++....:+++++print+"something"
+++....:+++++
something|code-block|syntax|javascript|2520060|每个人都已经注意到，使用else块会使代码更具可读性，并且只有在没有抛出异常时才会运行|2520061|In+[14]:+try:
+++++++++++++dict_["b"]
+++++++++except+KeyError:
+++++++++++++pass
+++++++++else:
+++++++++++++print+"something"
+++....:|2520062|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

You should be careful about using the finally block, as it is not the same thing as using an else block in the try, except. The finally block will be run regardless of the outcome of the try except.

<pre><code>In [10]: dict_ = {"a": 1}

In [11]: try:
 ....: dict_["b"]
 ....: except KeyError:
 ....: pass
 ....: finally:
 ....: print "something"
 ....: 
something
</code></pre>

As everyone has noted using the else block causes your code to be more readable, and only runs when an exception is not thrown

<pre><code>In [14]: try:
 dict_["b"]
 except KeyError:
 pass
 else:
 print "something"
 ....:
</code></pre>

blocks|key|2520072|text|奥普，你是对的。在Python中，/except之后的else是丑陋的。它指向另一个不需要的流控制对象：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2520073|try:
++++x+=+blah()
except:
++++print+"failed+at+blah()"
else:
++++print+"just+succeeded+with+blah"|code-block|syntax|javascript|2520074|一个完全清楚的等价物是：|2520075|try:
++++x+=+blah()
++++print+"just+succeeded+with+blah"
except:
++++print+"failed+at+blah()"|2520076|这比else子句要清楚得多。try/except之后的else并不是经常编写的，所以需要一段时间才能弄清楚其中的含义。|2520077|仅仅因为你能做一件事，并不意味着你应该做一件事。|2520078|语言中添加了许多功能，因为有人认为它可能会派上用场。问题是，功能越多，事情就越不清晰和明显，因为人们通常不会使用这些花哨的东西。|2520079|我这里只有5美分。我不得不跟在后面，清理许多由大学一年级的开发人员编写的代码，他们认为自己很聪明，希望以某种超级紧凑、超级高效的方式编写代码，而这只会让以后尝试读取/修改代码变得一团糟。我每天都投票支持可读性，星期天投票两次。|2520080|entityMap^0|H|I|0|0|0|0|0|0|O|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|11|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|12|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|13|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|14|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|S|3|T|5|6|7|18|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|19|8|@]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|X|$]]

OP, YOU ARE CORRECT. The else after try/except in Python is ugly. it leads to another flow-control object where none is needed:

<pre><code>try:
 x = blah()
except:
 print "failed at blah()"
else:
 print "just succeeded with blah"
</code></pre>

A totally clear equivalent is:

<pre><code>try:
 x = blah()
 print "just succeeded with blah"
except:
 print "failed at blah()"
</code></pre>

This is far clearer than an else clause. The else after try/except is not frequently written, so it takes a moment to figure what the implications are.

Just because you CAN do a thing, doesn't mean you SHOULD do a thing.

Lots of features have been added to languages because someone thought it might come in handy. Trouble is, the more features, the less clear and obvious things are because people don't usually use those bells and whistles.

Just my 5 cents here. I have to come along behind and clean up a lot of code written by 1st-year out of college developers who think they're smart and want to write code in some uber-tight, uber-efficient way when that just makes it a mess to try and read / modify later. I vote for readability every day and twice on Sundays.

blocks|key|44277|text|无论何时您看到以下内容：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|44278|try:
++++y+=+1+/+x
except+ZeroDivisionError:
++++pass
else:
++++return+y|code-block|syntax|javascript|44279|或者甚至是这样：|44280|try:
++++return+1+/+x
except+ZeroDivisionError:
++++return+None|44281|请考虑以下内容：|44282|import+contextlib
with+contextlib.suppress(ZeroDivisionError):
++++return+1+/+x|44283|entityMap^0|0|0|0|0|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|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Whenever you see this:

<pre><code>try:
 y = 1 / x
except ZeroDivisionError:
 pass
else:
 return y
</code></pre>

Or even this:

<pre><code>try:
 return 1 / x
except ZeroDivisionError:
 return None
</code></pre>

Consider this instead:

<pre><code>import contextlib
with contextlib.suppress(ZeroDivisionError):
 return 1 / x
</code></pre>

blocks|key|45322|text|这是我关于如何理解Python中的try-except-else-finally块的简单代码片段：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|45323|def+div(a,+b):
++++try:
++++++++a/b
++++except+ZeroDivisionError:
++++++++print("Zero+Division+Error+detected")
++++else:
++++++++print("No+Zero+Division+Error")
++++finally:
++++++++print("Finally+the+division+of+%25d/%25d+is+done"+%25+(a,+b))|code-block|syntax|javascript|45324|让我们试试div+1/1：|45325|div(1,+1)
No+Zero+Division+Error
Finally+the+division+of+1/1+is+done|45326|让我们尝试div+1/0|45327|div(1,+0)
Zero+Division+Error+detected
Finally+the+division+of+1/0+is+done|45328|entityMap^0|0|0|0|0|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|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

This is my simple snippet on howto understand try-except-else-finally block in Python:

<pre><code>def div(a, b):
 try:
 a/b
 except ZeroDivisionError:
 print("Zero Division Error detected")
 else:
 print("No Zero Division Error")
 finally:
 print("Finally the division of %d/%d is done" % (a, b))
</code></pre>

Let's try div 1/1:

<pre><code>div(1, 1)
No Zero Division Error
Finally the division of 1/1 is done
</code></pre>

Let's try div 1/0

<pre><code>div(1, 0)
Zero Division Error detected
Finally the division of 1/0 is done
</code></pre>

blocks|key|44233|text|请参见下面的示例，它说明了关于try-except+else-finally的所有内容：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|44234|for+i+in+range(3):
++++try:
++++++++y+=+1+/+i
++++except+ZeroDivisionError:
++++++++print(f"\ti+=+{i}")
++++++++print("\tError+report:+ZeroDivisionError")
++++else:
++++++++print(f"\ti+=+{i}")
++++++++print(f"\tNo+error+report+and+y+equals+{y}")
++++finally:
++++++++print("Try+block+is+run.")|code-block|syntax|javascript|44235|实现它，然后过来：|44236|++++i+=+0
++++Error+report:+ZeroDivisionError
Try+block+is+run.
++++i+=+1
++++No+error+report+and+y+equals+1.0
Try+block+is+run.
++++i+=+2
++++No+error+report+and+y+equals+0.5
Try+block+is+run.|44237|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

See the following example which illustrate everything about try-except-else-finally:

<pre><code>for i in range(3):
 try:
 y = 1 / i
 except ZeroDivisionError:
 print(f"\ti = {i}")
 print("\tError report: ZeroDivisionError")
 else:
 print(f"\ti = {i}")
 print(f"\tNo error report and y equals {y}")
 finally:
 print("Try block is run.")
</code></pre>

Implement it and come by:

<pre><code> i = 0
 Error report: ZeroDivisionError
Try block is run.
 i = 1
 No error report and y equals 1.0
Try block is run.
 i = 2
 No error report and y equals 0.5
Try block is run.
</code></pre>

From time to time in Python, I see the block:

<pre><code>try:
 try_this(whatever)
except SomeException as exception:
 #Handle exception
else:
 return something
</code></pre>

What is the reason for the try-except-else to exist?

I do not like that kind of programming, as it is using exceptions to perform flow control. However, if it is included in the language, there must be a good reason for it, isn't it?

It is my understanding that exceptions are not errors, and that they should only be used for exceptional conditions (e.g. I try to write a file into disk and there is no more space, or maybe I do not have permission), and not for flow control. 

Normally I handle exceptions as:

<pre><code>something = some_default_value
try:
 something = try_this(whatever)
except SomeException as exception:
 #Handle exception
finally:
 return something
</code></pre>

Or if I really do not want to return anything if an exception happens, then:

<pre><code>try:
 something = try_this(whatever)
 return something
except SomeException as exception:
 #Handle exception
</code></pre>

Is it a good practice to use try-except-else in Python?

Python

在Python中，我经常看到这样的代码块：try:   try_this(whatever)except SomeException as exception:   #Handle exceptionelse:   return something try-except-else存在的原因是什么？我不喜欢这种编程，因为...

问在Python中使用try-except else是一种好的实践吗？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Python中使用try-except else是一种好的实践吗？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Python中使用try-except else是一种好的实践吗？
EN