Is our current strategy for handling instrument errors optimal?

Right now, if an instrumentation callback raises an exception, we (a) print log (see #306) the traceback to stderr, (b) disable that instrument, (c) carry on.

This is the only place in trio that discards exceptions instead of handling or propagating them. Is this the right choice?

The motivation is that instrumentation gets called at all kinds of weird times where it's quite difficult to propagate an error, and it's not clear where to propagate to in any case, and while we in general prefer to crash early and noisily in general it's still probably true that no-one wants their instrumentation to take down their server (I think).

The downside are the obvious ones: it's easy to miss stuff dumped to stderr, if some tool is trying to automatically collect instrumentation then it could get wedged in unexpected ways if the instrument just disappears, etc.

So, I'm not entirely sure this is the best approach, and would be interested to hear what others think.

Start with the instrumentation callback error-handling behavior described in the issue: logging to stderr, disabling the instrument, and continuing. Review the two existing comments and establish an agreed policy for propagation, logging, and instrument state; the work is done when that policy is implemented and its behavior is covered by tests.