Seems rather expensive to put in CancelScope.__exit__? Not sure if it really makes any sense to be here in particular either, since exception groups can be raised anywhere, and they're not Trio-specific either.

Seems rather expensive to put in CancelScope.__exit__?

Maybe the runtime cost is too high yeah.

Not sure if it really makes any sense to be here in particular either, since exception groups can be raised anywhere, and they're not Trio-specific either.

That's the only place in trio where we call exception_group.derive (indirectly) from collapse_exception_group or exception_group.split. In addition, it's probably a good idea to let users know, even if this might not be their first encounter.

Codecov Report

Attention: Patch coverage is 96.22642% with 2 lines in your changes missing coverage. Please review.

Project coverage is 99.98920%. Comparing base (3de7996) to head (d8e853f).
Report is 6 commits behind head on main.

@@                 Coverage Diff                  @@
##                 main       #3176         +/-   ##
====================================================
- Coverage   100.00000%   99.98920%   -0.01081%     
====================================================
  Files             124         124                 
  Lines           18458       18510         +52     
  Branches         1215        1222          +7     
====================================================
+ Hits            18458       18508         +50     
- Misses              0           1          +1     
- Partials            0           1          +1     

I'm on the fence on whether we should check for this at runtime at all, esp when it gets this messy. And making people add derive to suppress the warning is quite a bit more expensive then adding a noqa.

On the other hand this would catch cases in libraries not running an appropriate linter, and an end user using that library+trio. But the error doesn't feel very trio-specific in the first case.

Actually this would false positive if someone mirrors the BaseExceptionGroup<->ExceptionGroup structure (where only BaseExceptionGroup has a derive)...

So maybe this isn't that useful of something to always warn about. I don't think everyone uses linters but I suppose if someone needs a custom ExceptionGroup odds are they use a linter?

I don't think this is Trio's job to detect, especially since the implementation is complicated and likely to be slow. I would much prefer to see us address the hazard with a lint, and/or a CPython change to warn in BaseExceptionGroup.__init_subclass__ if a subclass does not define derive.

I do think it's trio's place to try to prevent footguns (or even common mistakes) and I do think this qualifies. But I'll close this because:

• runtime cost of doubling (maybe?) execution time for exiting cancel scopes upon errors for what should be a very rare occurrence
• false positives are onerous and likely common, given how even ExceptionGroup doesn't implement derive

Mostly the second reason though. If someone comes up with a runtime thing that does better, I would love another attempt at this -- I totally could see myself ignoring documentation when playing around with a new thing (given I don't have linting in my REPL and I don't run lints until committing).