Provide typed exceptions (java bindings)

What is the problem you want to solve?

A lot of extra code is written to wrap the StatusRuntimeException with named/typed exceptions for the ledger api call response.

What is the solution you would propose?

Provide typed exceptions that provide easy understanding of the business error occurring

Example:

1. Create a User but the user already exists: throw a UserExistsException with cause: StatusRuntimeException.
2. Get User but user does not exist: throw a UserNotFoundException with cause: StatusRuntimeException.
3. Get Contract but does not exist: throw ContractNotFoundException with cause: StatusRuntimeException.

etc etc

Yes we can inspect the status codes and contents of the messages being returned by the ledger api, but it is boiler plate code that needs to be re-written each time. If you provided typed business exceptions, the boiler plate error handling code would be significantly reduced.

[daravep]

One additional note: we might want to add something like

class ChaosInterceptor
    extends ServerInterceptor {

  override def interceptCall[ReqT, RespT](
      call: ServerCall[ReqT, RespT],
      headers: Metadata,
      next: ServerCallHandler[ReqT, RespT],
  ): ServerCall.Listener[ReqT] = {
     // inject random outages
  }

we should add that and turn it on by default on the sandbox. if you build applications against it, it will inject random failures to force you to think about error handling (and let you test your error handling).

[daravep]

@StephenOTT Please have a read about our error codes: https://docs.daml.com/app-dev/grpc/error-codes.html#work-with-error-codes

I would strongly advise to not invent another way to handle errors, but rather make the error-code information accessible.

1. Every error comes with an error category: https://docs.daml.com/app-dev/grpc/error-codes.html#transientserverfailure
2. Every error category has an explicit advise on how to deal with that error. Example: https://docs.daml.com/app-dev/grpc/error-codes.html#invalidgivencurrentsystemstateresourceexists
3. Ideally, we surface that retry information.
4. We also need to include the rich error information. E.g. if you get contention on keys, the rich GRPC error contains the information on which key created the contention.
5. Here is our crappy scala code to decode the error-codes into a usable form: https://github.com/DACH-NY/canton/blob/main/community/common/src/main/scala/com/digitalasset/canton/error/DecodedRpcStatus.scala#L22