package error
- Alphabetic
- Public
- Protected
Type Members
- trait CantonBaseError extends BaseError
The main Canton error for everything that should be logged and notified
The main Canton error for everything that should be logged and notified
PREFER CantonError OVER CantonBaseError IN ORDER TO LOG THE ERROR IMMEDIATELY UPON CREATION TO ENSURE WE DON'T LOSE THE ERROR MESSAGE.
In many cases, we return errors that are communicated to clients as a Left. For such cases, we should use com.digitalasset.base.error.RpcError to report them.
For an actual error instance, you should extend one of the given abstract error classes such as CantonError.Impl further below (or transaction error).
There are two ways to communicate such an error: write it into a log or send it as a string to the user. In most cases, we'll do both: log the error appropriately locally and communicate it to the user by failing the api call with an error string.
When we log the error, then we write:
- ErrorCode
- ErrorName (name of the class defining the error code)
- The cause
- The context
The context is given by the following:
- All arguments of the error case class turned into strings (which invokes pretty printing of the arguments) EXCEPT: we ignore arguments that have the following RESERVED name: cause, loggingContext, throwable.
- The context of the logger (e.g. participant=participant1, synchronizer=da)
- The trace id.
- trait CombinedError extends RpcError
Combine several errors into one
Combine several errors into one
This is a rare case but can happen. In some cases, we don't have a single parent error like ParentCantonError, but many of them. This trait can be used for such situations.
Useful for situations with com.digitalasset.canton.util.CheckedT collecting several user errors.
- trait ContextualizedCantonError extends CantonBaseError with RpcError with LogOnCreation
- final case class GenericCantonRpcError(code: ErrorCode, context: Map[String, String], cause: String, resources: Seq[(ErrorResource, String)], correlationId: Option[String], traceId: Option[String], asGrpcStatus: Status, asGrpcError: StatusRuntimeException) extends RpcError with Product with Serializable
Generic canton error usually produced when an un-contextualized error want to return an error that has context
- sealed trait MediatorError extends Product with Serializable with PrettyPrinting
- trait ParentCantonError[+T <: CantonBaseError] extends CantonBaseError
Mixing trait for nested errors
Mixing trait for nested errors
The classic situation when we re-wrap errors:
sealed trait CryptoError extends CantonErrorBuilder sealed trait ProcessingError extends CantonErrorBuilder // NOTE, this error is NOT created within an ErrorCode, as we just inherit the parent error case class CryptoNoBueno(someArgs: String, parent: CryptoError) extends ProcessingError with ParentCantonError[CryptoError] { // we can mixin our context variables override def mixinContext: Map[String, String] = Map("someArgs" -> someArgs) }
Now in the following situation, the someCryptoOp method would generate the CryptoError. This CryptoError would be logged already (on creation) and therefore, the ParentCantonError disabled logging on creation.
for { _ <- someCryptoOp(..).leftMap(CryptoNoBueno("oh nooo", _)) } yields ()
- trait TransactionError extends CantonBaseError
- abstract class TransactionErrorImpl extends TransactionError
Transaction errors are derived from BaseCantonError and need to be logged explicitly
- trait TransactionErrorPrettyPrinting extends TransactionError with PrettyPrinting
- trait TransactionParentError[T <: TransactionError] extends TransactionError with ParentCantonError[T]
- sealed trait TransactionRoutingError extends TransactionError with Product with Serializable
- sealed trait TransactionRoutingErrorWithSynchronizer extends TransactionRoutingError
Value Members
- object CantonBaseError
- object CantonError
- object CantonErrorGroups
- object ErrorCodeUtils
- object FatalError
When a node encounters a fatal failure that it cannot gracefully handle yet then we exit the process.
When a node encounters a fatal failure that it cannot gracefully handle yet then we exit the process. A process/service monitor such as systemd/k8s will restart the process and the node may recover.
- object MediatorError extends MediatorErrorGroup with Serializable
- object TransactionRoutingError extends RoutingErrorGroup with Serializable
All routing errors happen before in-flight submission checking and are therefore never definite answers.