On Tue, Feb 25, 2025 at 12:39 PM 'Louis Wasserman' via grpc.io < grpc-io@googlegroups.com> wrote:
> With that said, I would strongly prefer not to add any features to > gRPC-Kotlin that are absent in gRPC-Java, to prevent future > incompatibilities if gRPC-Java adds the same features in a different, > incompatible form. Most feature requests I have seen for gRPC-Kotlin fail > that criterion. (I'm not certain if the specific example of global > exception handling is supported by gRPC-Java?) > Looking at https://github.com/grpc/grpc-kotlin/issues/371 , it seems this is for service handlers throwing exceptions. It isn't all that clear why this is being requested. I see one case that talks about logging. You can make an interceptor that catches exceptions, which seems to have already been discussed. I don't recall offhand how Coroutines work with exceptions and in grpc-kotlin, so they may be contributing to the difficulty. There could be some discussion for grpc-java to continue throwing exceptions up to the UncaughtExceptionHandler that is used in the Executor passed to serverBuilder.executor(). But right now our internal SerializingExecutor ends the RuntimeException propagation and logs directly. Errors are propagated up to UncaughtExceptionHandler. See issue 7725 <https://github.com/grpc/grpc-java/issues/7725>. -- 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 visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oOPurHOMTDVC2SdzxCZfni0BrEZnjfhrUk-v6QKAWyDsQ%40mail.gmail.com.
