[issue15209] Re-raising exceptions from an expression

Nick Coghlan added the comment: On Sun, Dec 9, 2012 at 2:59 AM, Ethan Furman wrote: > > Ethan Furman added the comment: > > There is one typo and one error in the first paragraph of the patch: > > > When raising a new exception (rather than > > using to bare ``raise`` to re-raise the >

[issue15209] Re-raising exceptions from an expression

Roundup Robot added the comment: New changeset 3b67247f0bbb by Nick Coghlan in branch '3.3': Issue #15209: Fix typo and some additional wording tweaks http://hg.python.org/cpython/rev/3b67247f0bbb New changeset 04eb89e078b5 by Nick Coghlan in branch 'default': Merge from 3.3 (issue #15209) http:

[issue15209] Re-raising exceptions from an expression

Ethan Furman added the comment: There is one typo and one error in the first paragraph of the patch: > When raising a new exception (rather than > using to bare ``raise`` to re-raise the ^ should be an 'a' > exception currently being handled), the > implicit exception chain can be made

[issue15209] Re-raising exceptions from an expression

Nick Coghlan added the comment: I rewrote the relevant section of the module docs (since they were a bit murky in other ways as well). Since I didn't answer the question earlier, the main reason a bare raise is permitted is because it's designed to be used to a bare except clause (e.g. when r

[issue15209] Re-raising exceptions from an expression

Roundup Robot added the comment: New changeset 8ba3c975775b by Nick Coghlan in branch '3.3': Issue #15209: Clarify exception chaining description http://hg.python.org/cpython/rev/8ba3c975775b New changeset 5854101552c2 by Nick Coghlan in branch 'default': Merge from 3.3 (Issue #15209) http://hg.

[issue15209] Re-raising exceptions from an expression

Changes by Ezio Melotti : -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue15209] Re-raising exceptions from an expression

Ethan Furman added the comment: Can we also get this committed before 3.3.0 final? -- ___ Python tracker ___ ___ Python-bugs-list mail

[issue15209] Re-raising exceptions from an expression

Ethan Furman added the comment: Any problems with the current doc patch? If not, can it be applied before RC1? -- ___ Python tracker ___

[issue15209] Re-raising exceptions from an expression

Tyler Crompton added the comment: As for the losing valuable debug information, much worse can be done: import sys try: x except NameError: print('An error occurred.', file=sys.stderr) sys.exit(1) This is obviously not how one should handle errors in development, but i

[issue15209] Re-raising exceptions from an expression

Ethan Furman added the comment: Removed sample code from doc patch as it was not robust, nor recommended practice. New patch is effectively: Note: Because using :keyword:`from` can throw away valuable debugging information, its use with a bare :keyword:`raise` is not supported. -

[issue15209] Re-raising exceptions from an expression

Ethan Furman added the comment: Tyler Crompton wrote: > I'm in a little over my head as I can't conceptualize __cause__, so I may be > looking over things. > > First, you, Ethan, said the following: > >> It's also not difficult to work around if you really want to toss the extra >> info: >>

[issue15209] Re-raising exceptions from an expression

Nick Coghlan added the comment: Correction, your try block is overbroad and will suppress errors in the getch implementation. This is better: try: _getch = windows_module.getch except NameError: _ getch = fallback_module.getch _getch() So I'm sticking with my persp

[issue15209] Re-raising exceptions from an expression

Nick Coghlan added the comment: If you don't want the exception context set *at all*, just use a pass statement to get out of the exception before trying the fallback. try: return windows_module.getch() except NameError: pass # No exception chaining fallback_module.

[issue15209] Re-raising exceptions from an expression

Tyler Crompton added the comment: I'm in a little over my head as I can't conceptualize __cause__, so I may be looking over things. First, you, Ethan, said the following: >It's also not difficult to work around if you really want to toss the extra >info: > >except NameError: >

[issue15209] Re-raising exceptions from an expression

Nick Coghlan added the comment: The purpose of the from clause in general is to change the exception *type* (for example, from KeyError -> AttributeError or vice-versa), or to add additional information without losing access to any previous information (like the original traceback). This is c

[issue15209] Re-raising exceptions from an expression

Ethan Furman added the comment: Nick Coghlan wrote: > The from clause is intended for replacing previous exceptions with *new* > exceptions, not editing the attributes of existing ones which may already > have a different __cause__ set. Huh. While I agree with the doc patch solution, I think t

[issue15209] Re-raising exceptions from an expression

Ethan Furman added the comment: Patch attached. It basically says: 8< Note: Because using :keyword:`from` can throw away valuable debugging information, its use with a bare :keyword:`raise` is not supported. If you are tryi

[issue15209] Re-raising exceptions from an expression

Ethan Furman added the comment: Okay, I see your point. It's also not difficult to work around if you really want to toss the extra info: except NameError: try: fallback_module.getch() except Exception as exc: raise exc from None

[issue15209] Re-raising exceptions from an expression

Nick Coghlan added the comment: The from clause is intended for replacing previous exceptions with *new* exceptions, not editing the attributes of existing ones which may already have a different __cause__ set. So - 1 from me, even for 3.4. A patch to the docs explaining that this is not support

[issue15209] Re-raising exceptions from an expression

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue15209] Re-raising exceptions from an expression

Ethan Furman added the comment: I agree that "raise from None" would be a nice enhancement. I don't see it going into 3.3 since we've hit feature freeze. Nick, do we need another PEP, or just consensus on pydev? (If consensus, I can bring it up there after 3.3.0final is released.) -

[issue15209] Re-raising exceptions from an expression

Changes by Tyler Crompton : -- nosy: +ncoghlan, stoneleaf ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue15209] Re-raising exceptions from an expression

Tyler Crompton added the comment: Relevent PEP: http://www.python.org/dev/peps/pep-0409/ -- ___ Python tracker ___ ___ Python-bugs-li

[issue15209] Re-raising exceptions from an expression

New submission from Tyler Crompton : As you know, a caught exception can be re-raised with a simple `raise` statement. Plain and simple. However, one cannot re-raise an error with this new `"from" expression` clause. For example: def getch(prompt=''): '''Get and return a character