On Mon, 19 July 2021, 6:32 pm Matt T. Proud, <m...@google.com> wrote:
> Our team maintains a framework that a bunch of client teams use to build > RPC servers (it supports gRPC as a transport). We largely hold the view > that a panic from foreign code can't meaningfully be recovered, because we > don't know why it panicked, what the state of the code was in, etc. For > instance, let's assume we want universal recovery behavior à la package > HTTP (we decided that we don't, but more on that below): > > - was a lock held that later needs to be released (note: sometimes > advanced code has locking behaviors that do not always match the semantics > of defer, even if we avoid this type of advanced design by default)? > - will some sort of state be corrupted silently as a result of the > panic (e.g., a record that is to be serialized to a data store is only > partially populated and with some measure of garbage)? > - will panic recovery put the system into an any other invalid state? > > For any of the considerations above (non-exhaustive), can we be reasonably > sure that code external to the user's directly-written code doesn't have a > problem area with above? So from our perspective, it is better to play it > safe and let the code panic and crash (it elicits rapid operator and > developer response). > > A small number of users do ask for some measure of "graceful" panic > handling in our framework as a middleware. We've considered offering it as > a user *opt-in* foot cannon with a clear warning about risks. The one > place I would consider it is potentially using it with a query of death > reporting mechanism that exports the failure to telemetry and logs and then > promptly crashes. > > Hope this helps. My opinion is by no way official. Just providing some > perspective about large scale code stewardship. > Thank you. I found it insightful. > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CANODV3%3DAoGNYVwqLnqnPoZPVS%2Bovvs3KWfiFSogbpzNga_5f4w%40mail.gmail.com.
