Is our current strategy for handling instrument errors optimal?

[njsmith]

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.

[smurfix]

Why not add a .detached(exc=None) method to the instrument? That'd allow it to clean up after itself. Of course if that also dies all bets are off, but at least you'd have a chance to exit gracefully.

[njsmith]

Hmm, so the idea would be that unhandled exceptions still automatically get printed and kick-out the instrument, but there would be a general life-cycle hook (or hooks, attached and detached) that an instrument could define, both to do any general setup and also as a last-chance to do something not-terrible when it crashes? That does sound reasonable. My initial instrument design didn't have any way to detect when an instrument was added/removed (you were just allowed to bodge around with the internal list directly), so this wasn't on my radar, but we're already switching to a more structured system (#257) so this could fit nicely after that transition finishes (which will be immediately after I finish up the 0.2.0 release).