On Fri, Feb 07, 2020 at 04:28:53PM +0200, Ram Rachum wrote:
> The idea is to add `raise as` syntax, that raises an exception while
> setting the currently caught exception to be the cause. It'll look like
> this:
>
> try:
> 1/0
> except ZeroDivisionError:
> raise as ValueError('Whatever')
This new syntax does nothing that the "raise ValueError from error" form
doesn't already do. It is redundant syntax for a feature that is rarely
necessary.
Is there any reason you think that the the only thing holding the Django
project back from using the "raise from" form is the extra typing?
If the Django devs don't want to use "raise from" to set the exception
cause, making it less typing to do something they don't want to do is
not going to convince them to do it. Especially since the earliest they
could use it would be after they have dropped support for all versions
of Python below 3.9.
> That's sad for me, because if Django doesn't accept the new syntax, and is
> okay with the inaccurate "During handling of" message between exceptions,
Is it inaccurate? Never mind, it probably doesn't matter, that's
Django's decision to make, not ours, and you obviously think it is.
> chances are low that there will be widespread adoption of the current
> `raise foo from bar` syntax.
Is that important?
Personally, I find that directly setting the exception cause to be a
feature looking for a use-case, except for the "raise from None" variant
which I use frequently. (Which is ironic, because the "from None" case
was added to the language much later than the "from error" case.)
> It's possible that introducing the simpler `raise as` would increase
> adoption and make users pay attention to the message between exception
> tracebacks.
Why do you want users to pay attention to the message between
tracebacks? And what makes you think that if "raise from error" was
adopted more the people reading tracebacks would pay attention to the
message between tracebacks?
In my experience, 9 times out of 10 the only relevant part of the
traceback is the final line showing the direct failing line. It's
relatively rare that I care about the rest of the traceback. I doubt I
would often care about the difference between these two:
During handling of the above exception, another exception occurred
The above exception was the direct cause of the following exception
when reading the traceback. Technically the message does add information
to the traceback, but in my experience it is of marginal usefulness.
--
Steven
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FAOPYHH5HNCPAF2QJIXLO5WON5ME4GRP/
Code of Conduct: http://python.org/psf/codeofconduct/
