Better ergonomics for exceptions #56
Description
Our error-reporting story is tolerable at this point (see #49 for some history), but could definitely still be improved. This collects some misc ideas:
- Our tracebacks are very cluttered and hard to read (lots of internal helper functions etc. all over the place) – can we cut this down?
- Rewrite nursery context manager without
@asynccontextmanagerand@async_generatorto reduce extraneous frames - Avoid raising internally to communicate gathered exceptions up to nursery exit (see implement open_nursery with explicit context manager #612 (comment) and Better ergonomics for exceptions #56 (comment))
- Maybe elide trio-internal stuff with [...4 frames skipped...] to help users focus on their code? May be at odds with pushing our traceback logic down to the interpreter.
- Rewrite nursery context manager without
- Tracebacks should include task context, like: as an exception propagates in (
Error.unwrap) and out (_task_finished) of tasks, update a record likeexc.__trio_task_context__with entries like(len(tb), "exit", task), and use them to add context to printed tracebacks. (The need to computelenis a bit unfortunate though... I guess ideally these should be attributes on the tb objects themselves? But tb objects don't have__dict__s. Or we could just stash the tb object.)MultiError.filterneeds to be careful to propagate these correctly when propagating tracebacks. -
MultiError.catchis OK, but could be better- We don't propagate
__context__onMultiErrors - We should really have an async version... but bpo29600 makes this difficult!
- The filter interface is maybe a bit awkward and error prone?
- If people try to work around the awkwardness by doing some sort of
try: raise exc except: ...thing, then they get corrupt tracebacks (we assume that the filter callback doesn't touch the traceback). We could potentially detect new tb frames appearing and fix them up.
- We don't propagate
- Better IPython integration: right now we override the printing of
MultiErrors and use our regularMultiErrorprinting code. This is good b/c it gives full information, but bad b/c it loses out on IPython's enhanced exception formatting. Better ergonomics for working with MultiErrors #49 has some notes on how this might be possible to get both. (Note that this becomes more of an issue if we do as suggested above and start customizing all exception output and not justMultiError!) Possibly should chat with the IPython devs about this.