#16245: send_robust should include traceback in response when Exception occurs
-------------------------------------+-------------------------------------
Reporter: jsdalton | Owner: nobody
Type: | Status: new
Cleanup/optimization | Component: Core (Other)
Milestone: | Severity: Normal
Version: SVN | Keywords: signals
Resolution: | Has patch: 1
Triage Stage: Design | Needs tests: 0
decision needed | Easy pickings: 0
Needs documentation: 0 |
Patch needs improvement: 0 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
Comment (by jsdalton):
Replying to [comment:4 aaugustin]:
> I understand the problem you're trying to solve.
>
> What I don't understand is why you say your solution is backwards
compatible. I think the code I've shown is a common pattern, and it would
break after your patch, wouldn't it?
Ah, thanks. I misunderstood your point of concern. You are indeed correct.
I overlooked this usage pattern for a list of tuples, which would break
with this change.
I considered two other API alternatives, though I was not at the time
particularly satisfied with either:
* Rather than returning the error instance as the second argument to the
tuple pair, return the three tuple `(type, value, traceback)` -- i.e. the
same three tuple returned by `sys.exc_info()`, where type is the Exception
class and value is the exception instance. This of course also breaks
current implementations.
* Add a private (or otherwise) variable to the exception instance, e.g.
`__traceback__`, a la Python 3. I mentioned this in my first comment
above. This solution does not break current implementations. It solves the
problem. It's also in keeping with a design decision that the larger
Python community agreed is a "good" one, i.e. to attach call stack
information about the error to the exception instance.
I'm not sure which of these alternatives I prefer. Since my original
solution breaks current implementations, I'm probably least satisfied with
it. The first alternative I propose (adding the three tuple in place of
the error instance) is logical and also useful. For example, if you're
passing error information on to a logging object (that's my particular use
case), you can pass that second item in the tuple directly to the
`exc_info`kwarg and the logging class will handle communicating all the
necessary info for you. I think this is the "best" solution if it was
agreed that it was acceptable to break current implementations with this
change.
The third solution (adding a traceback attribute) has the advantage of
being highly unlikely to break existing implementations. It's possible
that it still could break them, e.g. if `__traceback__` was the chosen
attribute and someone was already assigning that during error handing, and
this overwrote it. It's of course highly unlikely that the new traceback
would be different than the one assigned, but the possibility exists. It
also feels a bit weird to me to just add an arbitrary attribute to an
object we know nothing about, except that it's probably an exception
object. There may be stronger, more logical reasons than just "it feels
weird". Anyhow, strong advantage of this is it doesn't break current
implementation, weakness is it's the messiest and probably most confusing
and "magical" seeming.
Not sure if this is the appropriate place to continue this discussion, and
perhaps it should be moved to the developers list. But if anyone has
feedback on the above I'd be interested in hearing it.
--
Ticket URL: <https://code.djangoproject.com/ticket/16245#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
