This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
| Author | pitrou |
|---|---|
| Recipients | Rhamphoryncus, benjamin.peterson, pitrou |
| Date | 2008年06月06日.21:54:07 |
| SpamBayes Score | 0.059161108 |
| Marked as misclassified | No |
| Message-id | <1212789249.29.0.839752844029.issue3021@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
With or without my patch, bare "raise" inside a "finally" statement raises a "RuntimeError: no active exception to re-raise". (except, of course, when the try/finally is itself enclosed in an except block) That's because a finally block is not considered an exception handler. I don't think there's any reason to change this. I'm not for adding syntax errors. After all the bare "raise" statement just does the moral equivalent of re-raising sys.exc_info() verbatim. In those situations where sys.exc_info() would return a non-empty result, why shouldn't "raise" be accepted as well? |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年06月06日 21:54:09 | pitrou | set | spambayes_score: 0.0591611 -> 0.059161108 recipients: + pitrou, Rhamphoryncus, benjamin.peterson |
| 2008年06月06日 21:54:09 | pitrou | set | spambayes_score: 0.0591611 -> 0.0591611 messageid: <1212789249.29.0.839752844029.issue3021@psf.upfronthosting.co.za> |
| 2008年06月06日 21:54:08 | pitrou | link | issue3021 messages |
| 2008年06月06日 21:54:07 | pitrou | create | |