> +1 on chaining exceptions. I think the information is useful.
Absolutely. But exceptions are **already** chained, regardless of whether
we
use the `from` syntax.
Without the from clause exceptions are "implicitly" chained. With the from
claus it's "explicit".
Just the same tracebacks are presented, in just the same order.
The only difference is the string that divides them:
```
The above exception was the direct cause of the following exception:
```
vs
```
During handling of the above exception, another exception occurred:
```
That change in string isn't worth 380+ changes over 100 files.
* We're obscuring the history for nothing, and...
* Whilst I **think** there's no danger in this case, bulk edits are by
their nature
unconsidered, and there is the ever-present risk of regression.
Beyond that, the from syntax is simply more verbose. In the PR the changes
are
all adding a unneeded `as e`, followed by an equally unneeded `from e`.
Looking at the diff, the comparison that comes to mind is if we went
through
and replaced all percent formatting with format()
So I'm -1 on merging the PR. I think we should close the ticket as wontfix.
I would ask everyone to clarify exactly what they think the benefits of the
proposed change are, and to follow-up if there's a hidden benefit I've
missed.
I'm not anti the from clause in general. I use it myself, and in any given,
considered case, I see no reason not to use it in Django.
This is different from insisting it must be used, and rightly so, because,
as I understand it, the target use case for from is when you want to
provide more targeted exception logging.
Take this case:
def inner():
raise Exception("This is the one we really want to show the user.")
def middle():
try:
inner()
except:
raise Exception("All sorts of stuff that's not so interesting.")
def outer():
try:
middle()
except Exception as e:
msg = "We cut out the unimportant stuff, to focus on what's
important."
raise Exception(msg) from e.__context__
if __name__ == '__main__':
outer()
Here the use of from makes the traceback exactly how we want it:
$ python exceptions.py
Traceback (most recent call last):
File "exceptions.py", line 9, in middle
inner()
File "exceptions.py", line 4, in inner
raise Exception("This is the one we really want to show the user.")
Exception: This is the one we really want to show the user.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "exceptions.py", line 23, in <module>
outer()
File "exceptions.py", line 19, in outer
raise Exception(msg) from e.__context__
Exception: We cut out the unimportant stuff, to focus on what's
important.
Contrasted to not using from, where we just get everything:
$ python exceptions.py
Traceback (most recent call last):
File "exceptions.py", line 9, in middle
inner()
File "exceptions.py", line 4, in inner
raise Exception("This is the one we really want to show the user.")
Exception: This is the one we really want to show the user.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "exceptions.py", line 16, in outer
middle()
File "exceptions.py", line 11, in middle
raise Exception("All sorts of stuff that's not so interesting.")
Exception: All sorts of stuff that's not so interesting.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "exceptions.py", line 23, in <module>
outer()
File "exceptions.py", line 19, in outer
raise Exception(msg)
Exception: We just output everything because we didn't use from.
That's where the real benefit lies.
So, summary:
* Exception chaining is the default. We already have that.
* Short of something I missed (which is always possible 🙂) there's no
reason for the bulk edit being proposed here.
Kind Regards,
Carlton
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/8fd6f226-7ee6-403b-9a8e-9d02408a87c2%40googlegroups.com.
