[Proposal] Consistent error reporting in pluggable components

[philliphoff]

Describe the proposal

It was a design goal to prevent/minimize exposure of gRPC concepts within the Pluggable Components SDK. However, the .NET gRPC SDK on which it is built does not propagate (by default) .NET standard exceptions. Components intending to report specific errors to applications must currently use gRPC-specific mechanisms (e.g. throw RpcException directly). As a secondary issue, gRPC clients/services have unofficially standardized on a means of reporting extended error information across gRPC boundaries, but this mechanism is not well supported on .NET, nor universally supported by the Dapr runtime (i.e. in how it traps/reports errors to applications).

There are several options:

• Enable global pass-through of exceptions (i.e. GrpcServiceOptions.EnableDetailedErrors = true)
• Rewrite a subset of exceptions using gRPC interceptors
• Recommend use of RpcException (including or not, extended information)
• Provide a mechanism to report extended information that doesn't rely on RpcException

My current thinking is the latter; to expose a specific type (e.g. DaprPluggableComponentException) for exceptions that are specifically intended to be returned to the caller, and have it accept the existing, extended error types (which are "RPC" specific but not "gRPC" specific), with the gRPC specific handling hidden away in the SDK infrastructure. This would also seem aligned with current thinking around how error handling should be made more consistent in the Dapr runtime itself (see dapr/dapr#6068).

[tmacam]

Cool. I think we need to wait to see what will be the result of dapr/dapr#6068 before we can think on how to standardize those.