Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make it easier to tell where a Cancelled exception came from #44

Open
njsmith opened this issue Feb 11, 2017 · 4 comments
Open

Make it easier to tell where a Cancelled exception came from #44

njsmith opened this issue Feb 11, 2017 · 4 comments

Comments

@njsmith
Copy link
Member

njsmith commented Feb 11, 2017

Right now repr(exc) just gives Cancelled() which is not so helpful when trying to debug. Maybe something like <Cancelled, scope 3 in task some_func-3>?

(Even nicer if we could provide line numbers, but I think that would be expensive? Also misleading when the scope is hidden inside open_nursery or move_on_at.)

@oremanj
Copy link
Member

oremanj commented Mar 12, 2019

Tasks have had names for a while, and Cancelled exceptions don't know what scope will catch them anymore, so I'm not sure there's anything left to be done here.

@oremanj oremanj closed this as completed Mar 12, 2019
@sorcio
Copy link
Contributor

sorcio commented Mar 12, 2019

@oremanj I think this is still relevant, or at least deserves a new proposal. It's still true that Cancelled exceptions are a bit too anonymous when debugging, and adding extra context info would help "user happiness".

@smurfix
Copy link
Contributor

smurfix commented Mar 12, 2019

IMHO the way to fix this is to store the stack of the caller of the .cancel method so that the actual Cancelled exception can use it in a raise from or similar.

@oremanj oremanj changed the title Give names to tasks and cancel scopes, and put the names in Cancelled exceptions Make it easier to tell where a Cancelled exception came from Mar 12, 2019
@oremanj oremanj reopened this Mar 12, 2019
@mchhoy
Copy link

mchhoy commented May 12, 2021

Hi, I just spent a few hours debugging an issue where instead of:

await trio.sleep_until(x)

I had typed:

await trio.move_on_after(x)

And this was causing some phantom cancellations - something like this may have helped :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants