search

dabeaz / curio

Good Curio!
Other
4.04k stars 244 forks source link

Should Curio clean up tracebacks (Discussion) #277

Closed dabeaz closed 6 years ago

dabeaz commented 6 years ago

Nathaniel Smith recently posted a blog about cleaning up tracebacks in Trio. https://vorpus.org/blog/beautiful-tracebacks-in-trio-v070/

I will admit that tracebacks in Curio are also pretty complicated and was just wondering if it would make sense to do anything like that here? I have mixed thoughts. On one hand, it's nice to get a short traceback. On the other hand, it might be nice to just leave the traceback "as is" in order to get a truly accurate view of what happened when debugging.

I'll leave it here for discussion.

kdart commented 6 years ago

I prefer the framework not print tracebacks itself, but just pass through exceptions. Then a user can use a debugger to view the traceback.

I put "debugger hooks" in my own code, that can automatically invoke a debugger on an otherwise uncaught exception.

However, I've been trying to figure out how to access the stack frame of a coroutine for inspection. There doesn't seem to be any access to it. Do you know of one?

dabeaz commented 6 years ago

So far as I know, Trio is actually cleaning the raw tracebacks passed back to the user--it's not merely a printing enhancement.

With respect to stack frames of coroutines, you might take a look at some of the functionality in curio/task.py. Specifically, the _get_stack() function extracts stack frames from coroutines (although there are some bugs/limitations of Python in making it work for all cases).

dabeaz commented 6 years ago

I'm going to leave the exceptions alone.

imrn commented 6 years ago

I too prefer that an async framework / library should not mess with any underlying exception. Framework should be 100% transparent for the exceptions.

Note that, complexity of a traceback is related with the complexity of the framework. So far, it is manageable in curio.

dabeaz commented 6 years ago

I think there is a general conflict concerning just how much an async library should be doing for you. I think on the whole, I'm more in the camp of having it stay out of the way as much as possible. So, I don't really want to be doing things like altering exceptions, wrapping results up in all kinds of layers, or implicitly messing around with the I/O system. I don't know if people view Curio as magical or not, but to me, there's very little actual magic going on with respect to how it works.