A human readable string indicating the error

The error code, usually passed in as implicit where the error class is defined

The context (declared fields) of this error

Controls whether a definite_answer error detail is added to the gRPC status code

Contains the location where the error has been created.

Flag to control if an error should be logged at creation

Generally, we do want to log upon creation, except in the case of "nested" or combined errors, where we just nest the error but don't want it to be logged twice. See com.digitalasset.canton.error.ParentCantonError as an example.

The logging context obtained when we created the error, usually passed in as implicit via com.digitalasset.canton.logging.NamedLogging

The context we want to mix-in

The parent error that we want to nest

The resources related to this error

We return the set of resources via com.google.rpc.ResourceInfo. Override this method in order to return resource information via com.google.rpc.Status

Returns retryability information of this particular error

In some cases, error instances would like to provide custom retry intervals. This can be achieved by locally overriding this method.

Do not use this to change the contract of the error categories. Non-retryable errors shouldn't be made retryable. Only use it for adjusting the retry intervals.

An optional argument to log exceptions

If you want to log an exception as part of your error, then use the following example:

object MyCode extends ErrorCode(id="SUPER_DUPER_ERROR") { case class MyError(someString: String, throwable: Throwable) extends SomeInternalError( cause = "Something failed with an exception bla", throwableO = Some(throwable) ) }

NOTE: This throwable's details are not included the exception communicated to the gRPC clients so if you want them communicated, you need to explicitly add them to the e.g. context map or cause string.