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.