为什么没有尝试 - 除了 - 最后？ [英] Why no try-except-finally ?

问题描述

之前可能已经讨论过这个问题了，但是我很困惑为什么Python

不支持同时包含except~和~a finally子句，如下所示：


试试：

加注RuntimeException

除了：

print"答案是什么？ ;

终于：

打印42


这不行，因为我同时使用''除''和' '最后''。我不是说

它应该工作，我想知道它为什么不行。不过，我想到了它的价格为b / b $ b秒，并提出了特别的嵌套式尝试成语，我称之为：


尝试：

试试：

加注RuntimeException

除了：

print"答案是什么？ ;

终于：

打印42


按预期工作：异常被抛出，问题在
''except''子句，然后在''finally''

子句中回答问题。当然，在现实世界的代码中，我们不会通过异常处理提出问题并给出

答案，但执行的路径才是最重要的。

这个成语unPythonic不知何故？ （嵌套尝试的东西确实看起来很奇怪......）或者它是我们应该这样做的方式吗？或者有什么我想念的吗？


- Kef

This may have been discussed before, but I''m kind of confused as to why Python
doesn''t support having both an except ~and~ a finally clause, like this:

try:
raise RuntimeException
except:
print "What is the answer?"
finally:
print 42

This doesn''t work because I use both ''except'' and ''finally''. I''m not saying
that it SHOULD work, I''m wondering why it doesn''t. I thought about it for a
second, though, and came up with the ad-hoc "nested-try idiom", as I call it:

try:
try:
raise RuntimeException
except:
print "What is the answer?"
finally:
print 42

This works as expected: the exception gets thrown, the question gets asked in
the ''except'' clause, and then the question gets answered in the ''finally''
clause. Of course in real-world code we wouldn''t be asking questions and giving
answers via exception-handling, but the path of execution is what counts. Is
this idiom unPythonic somehow? (The nested-try thing does look odd...) Or is it
the way we''re supposed to do it? Or is there something I''m missing?

- Kef

推荐答案

> ;这可能以前已经讨论过，但是我很困惑为什么

>This may have been discussed before, but I''m kind of confused as to why

Python
不支持同时包含except~和~a finally子句，就像这样：

尝试：
提高RuntimeException
除了：
打印答案是什么？最后：
打印42

这不起作用，因为我同时使用''除''和'''''。我不是说它应该工作，我想知道它为什么不行。不过我想到了它的第二个，并提出了特设的嵌套式尝试成语，我称之为：

尝试：
尝试：
提高RuntimeException
除了：
打印答案是什么？最后：
打印42

预期：抛出异常，在''except''子句中询问问题，然后在''finally''
子句中回答问题。当然，在现实世界的代码中，我们不会通过异常处理来提问和提供答案，但执行的路径才是最重要的。
这个成语unPythonic不知何故？ （嵌套尝试的东西看起来很奇怪......）或者是
它我们应该这样做的方式？或者有什么我想念的东西？

- Kef


我在帖子中搞砸了几件事，呵呵。首先，当然是
RuntimeException应该是RuntimeError。另一个是这个（嵌套的试试

成语）：

试试：
试试：
引发RuntimeException
除了：
打印答案是什么？最后：
打印42

Python
doesn''t support having both an except ~and~ a finally clause, like this:

try:
raise RuntimeException
except:
print "What is the answer?"
finally:
print 42

This doesn''t work because I use both ''except'' and ''finally''. I''m not saying
that it SHOULD work, I''m wondering why it doesn''t. I thought about it for a
second, though, and came up with the ad-hoc "nested-try idiom", as I call it:

try:
try:
raise RuntimeException
except:
print "What is the answer?"
finally:
print 42

This works as expected: the exception gets thrown, the question gets asked in
the ''except'' clause, and then the question gets answered in the ''finally''
clause. Of course in real-world code we wouldn''t be asking questions and
giving
answers via exception-handling, but the path of execution is what counts. Is
this idiom unPythonic somehow? (The nested-try thing does look odd...) Or is
it
the way we''re supposed to do it? Or is there something I''m missing?

- Kef
I messed up a couple things in my post, heh. First off, of course
RuntimeException should be RuntimeError. The other is that this (the nested try
idiom):
try:
try:
raise RuntimeException
except:
print "What is the answer?"
finally:
print 42

应改为：


尝试：

尝试：

提高RuntimeError

除外：

print"答案是什么？

加薪＃< - 已经忘记了

终于：

print 42

- Kef

should instead be this:

try:
try:
raise RuntimeError
except:
print "What is the answer?"
raise # <- HAD BEEN FORGOTTEN
finally:
print 42

- Kef

" KefX" <柯********** @ aol.comNOSPAM>在消息中写道

news：20 *************************** @ mb-m22.aol.com。 ..

"KefX" <ke**********@aol.comNOSPAM> wrote in message
news:20***************************@mb-m22.aol.com...

这个成语unPythonic不知何故？ （嵌套尝试的东西看起来很奇怪......）或者
是我们应该这样做的吗？或者有什么我想念的吗？

this idiom unPythonic somehow? (The nested-try thing does look odd...) Or is it the way we''re supposed to do it? Or is there something I''m missing?

根据文档，尝试...最终声明的目的是

to确保获得的资源将再次被释放，如


self.lock.acquire（）

尝试：

..do无论我们应该做什么;

......它可能会在这里或在不同的模块中失败等。

......例外情况可能会被捕获

最后：

...但是我们总是*在这里结束*

...而且未被捕获的异常也从这里重新提出（我认为）

...所以正确的事情发生

self.lock.release（）


这样就可以释放资源，无论是否发生任何例外情况......

发生在try：和finally之间：


分离可能是因为try..finally的目的不同

来自异常处理和混合两者会晦涩难懂（或者可能

引擎盖下有一些巫术）。

According to the documentation the purpose of a try...finally statement is
to ensure that aquired ressources will be freed again as in

self.lock.acquire()
try:
..do whatever we are supposed to do;
...it may fail here or in a different module etc.
...exceptions may be caught or not
finally:
...but we always end *here*
...and uncaught exceptions are re-raised from here too (i think)
...so that "the right thing" happens
self.lock.release()

so that the ressource is released regardless of any exceptions etc. that
happens between the try: and the finally:

The separation is probably because the purpose of try..finally is different
from exception handling and mixing the two would obscure that (or maybe
there is some wizardry under the hood).

>分离可能是因为尝试的目的..最后是不同的

>The separation is probably because the purpose of try..finally is different

来自异常处理和混合两者会掩盖那些（或者可能是引擎盖下的一些巫术）。

from exception handling and mixing the two would obscure that (or maybe
there is some wizardry under the hood).

我不知道。其他语言，如Java支持try-catch-finally等。 （或者我们称之为
" try-except-finally"），我不知道怎么缺少

限制做什么坏事比方说，降低代码的清晰度。


我提出这个问题是因为我最初用我的游戏代码写了这个：


尝试：

PlayGame（）

除外：

err_msg =" FATAL ERROR：" + sys.exc_info（）[0]

logger.critical（err_msg）

终于：

DeInit（）


换句话说，如果出现问题，会在日志中打印出错误消息

，然后在任何一种情况下，我的游戏都会尝试优雅地退出。

当然，在没有finally的情况下重写它：没什么大不了的（只需在except块中写入DeInit（）

并在块之后再次写入）...在此案件。如果我想要

执行一堆行怎么办？代码重复很糟糕。好吧，我可以写一个

本地函数，只是让它在这两种情况下调用它，但感觉就像

矫枉过正。因此，我想出了''嵌套尝试成语''：


试试：

试试：

PlayGame（ ）

除外：

err_msg =" FATAL ERROR：" + sys.exc_info（）[0]

logger.critical（err_msg）

up

终于：

DeInit（）


但它看起来有点难看。但是如果需要的话，只需将'/ b'中的语句更改为''finally''块也很容易。但嵌套式尝试看起来很奇怪，更糟糕的是，你需要记住将'加注'放在除了块之外（记得我忘了

这样做在我原来的帖子中！），错误处理代码往往是经过最少测试的
...


我不知道。更多想法？


- Kef

I dunno. Other languages such as Java support "try-catch-finally" (or
"try-except-finally" as we''re calling it), and I don''t see how the lack of
restrictions does anything bad like, say, reduce the clarity of code.

I bring this up because I originally wrote this in my game code:

try:
PlayGame()
except:
err_msg = "FATAL ERROR: " + sys.exc_info()[0]
logger.critical(err_msg)
finally:
DeInit()

In other words, if something went wrong, an error message would be printed out
to the log, and then in either case, my game would try to exit gracefully. Of
course, rewriting it without the finally: is no big deal (just write DeInit()
in the except block and again after the block)...in this case. What if I wanted
to execute a bunch of lines? Code duplication is bad. Well, I could write a
local function and just have it call THAT in both cases, but that felt like
overkill. Thus, I came up with the ''nested-try idiom'':

try:
try:
PlayGame()
except:
err_msg = "FATAL ERROR: " + sys.exc_info()[0]
logger.critical(err_msg)
raise
finally:
DeInit()

But it looks kind of ugly. But it''s still easy to just change the statements in
the ''finally'' block if needed. But the nested-try looks strange, and worse, you
have to remember to put the ''raise'' in the except block (remember I forgot to
do this in my original post!), and error-handling code tends to be the
least-tested...

I dunno. More thoughts?

- Kef

这篇关于为什么没有尝试 - 除了 - 最后？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！