Packages

package error

Ordering
  1. Alphabetic
Visibility
  1. Public
  2. Protected

Type Members

  1. trait BaseCantonError 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

    In many cases, we return errors that are communicated to clients as a Left. For such cases, we should use CantonError 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: 1) ErrorCode 2) ErrorName (name of the class defining the error code) 3) The cause 4) The context

    The context is given by the following: 1) 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. 2) The context of the logger (e.g. participant=participant1, domain=da) 3) The trace id.

  2. trait CantonError extends BaseCantonError

    CantonErrors are logged immediately when they are created.

    CantonErrors are logged immediately when they are created. Therefore, they usually expect an implicit com.digitalasset.canton.logging.ErrorLoggingContext to be around when they are created. If you are creating such an error in a class extending com.digitalasset.canton.logging.NamedLogging, then the implicit function will provide you with such a context. If you don't have that context, then you can also use BaseCantonError and invoke the logging yourself at a later point in time (which is what we do, for example, with TransactionError).

  3. trait CombinedError[+T <: BaseCantonError] extends AnyRef

    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.

  4. case class DecodedRpcStatus(id: String, category: ErrorCategory, correlationId: Option[String], retryIn: Option[Duration], context: Map[String, String], resources: Map[ErrorResource, Seq[String]]) extends Product with Serializable

    Decoded form of com.google.rpc.Status as generated by our errors

    Decoded form of com.google.rpc.Status as generated by our errors

    We use com.google.rpc.Status (java) and com.google.rpc.status.Status (scala) to store and ship error information via GRPC. However, extracting this information from the object is a bit cumbersome.

    Therefore, we support the UX by providing a set of conversion utilities to make the information stored better accessible.

  5. abstract class ErrorCodeWithEnum[T] extends ErrorCode
  6. trait HasDegradationState[E <: CantonError] extends AnyRef

    This trait should be implemented by classes that can experience a degradation.

    This trait should be implemented by classes that can experience a degradation. It has methods that enable the tracking and logging-upon-resolution of stateful degradation. Example scenario:

    • A participant is anomalously disconnect from domain -> we log an error and track that the error/degradation has occurred
    • The participant is reconnected to the domain -> we log a resolution message referring to the previous error and log that the degradation has been fixed For an example use of this trait see CantonSyncService
    E

    error type we are tracking

  7. abstract class LoggingTransactionErrorImpl extends TransactionErrorImpl
  8. trait ParentCantonError[+T <: BaseCantonError] extends BaseCantonError

    Mixing trait for nested errors

    Mixing trait for nested errors

    The classic situation when we re-wrap errors:

    sealed trait CryptoError extends CantonError

    sealed trait ProcessingError extends CantonError

    // 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 ()

  9. trait TransactionError extends BaseCantonError
  10. abstract class TransactionErrorImpl extends TransactionError

    Transaction errors are derived from BaseCantonError and need to be logged explicitly

  11. trait TransactionErrorWithEnum[T] extends TransactionError
  12. abstract class TransactionErrorWithEnumImpl[T] extends TransactionErrorWithEnum[T]

    Transaction errors are derived from BaseCantonError and need to be logged explicitly

  13. trait TransactionParentError[T <: TransactionError] extends TransactionError with ParentCantonError[T]

Ungrouped