On 1/27/2012 2:54 PM, Guido van Rossum wrote:
On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furman<et...@stoneleaf.us> wrote:
Guido van Rossum wrote:
Did you consider to just change the
words so users can ignore it more easily?
Yes, that has also been discussed.
Speaking for myself, it would be only slightly better.
Speaking for everyone that wants context suppression (using Steven
D'Aprano's words): chained exceptions expose details to the caller that are
irrelevant implementation details.
Especially if the users are non-programmer app users.
It seems to me that generating the amount of information needed to track
down errors is a balancing act between too much and too little; forcing the
print of previous context when switching from exception A to exception B
feels like too much: at the very least it's extra noise; at the worst it
can be confusing to the actual problem. When the library (or custom class)
author is catching A, saying "Yes, expected, now let's raise B instead", A
is no longer necessary.
I find double tracebacks to be 'jarring'. If there is a double bug, one
in both the try and except blocks, it *should* stand out. If there is
just one bug and the developer merely wants to rename it and change the
message, it should not.
Also, the programmer is free to *not* use 'from None', leaving the complete
traceback in place.
Ok, got it. The developer has to explicitly say "raise<something>
from None" and that indicates they have really thought about the issue
of suppressing too much information and they are okay with it. I dig
that.
Now that I have been reminded that 'from x' was already added to raise
statements, I am fine with reusing that. I still think it 'sticks out'
more than the 'as' version, but when reading code, having (rare) info
suppression stick out is not so bad.
The PEP does not address the issue of whether the new variation of raise
is valid outside of an except block. My memory is that it was not to be
and I think it should not be. One advantage of the 'as' form is that it
is clear that raising the default as something else is invalid if there
is no default.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
