Type Members

1.  trait BaseError extends LocationMixin

   The main error interface for everything that should be logged and notified.

   The main error interface for everything that should be logged and notified.

   There are two ways to communicate an error to the user: write it into a log or send it as a string. 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.

2.  trait ContextualizedError extends BaseError

   Base class for errors for which error context is known at creation.

3.  trait ContextualizedErrorLogger extends AnyRef

   Abstracts away from the logging tech stack used.

4.  class DamlError extends ContextualizedError
5.  class DamlErrorWithDefiniteAnswer extends DamlError

6.  final case class Description(description: String) extends Annotation with StaticAnnotation with Product with Serializable
7.  sealed trait ErrorCategory extends AnyRef

   Standard error categories

   Standard error categories

   Ideally, all products will return errors with appropriate error codes. Every such error code is associated with an error category that defines how the error will appear in the log file and on the api level.

8.  final case class ErrorCategoryRetry(duration: Duration) extends Product with Serializable

   Default retryability information

   Default retryability information

   Every error category has a default retryability classification. An error code may adjust the retry duration.

9.  final case class ErrorClass(groupings: List[Grouping]) extends Product with Serializable

   Used to hierarchically structure error codes in the official documentation.

10.  abstract class ErrorCode extends AnyRef

    Error Code Definition

    Error Code Definition

    We want to support our users and our developers with good error codes. Therefore, every error that an API returns should refer to a documented error code and provide some context information.

    Every error code is uniquely identified using an error-id of max 63 CAPITALIZED_WITH_UNDERSCORES characters

    Errors are organised according to ErrorGroups. And we separate the error code definition (using a singleton by virtue of using objects to express the nested hierarchy) and the actual error.

    Please note that there is some implicit argument passing involved in the example below:

    object SyncServiceErrors extends ParticipantErrorGroup { object ConnectionErrors extends ErrorGroup { object DomainUnavailable extends ErrorCode(id="DOMAIN_UNAVAILABLE", ..) { case class ActualError(someContext: Val) extends BaseError with SyncServiceError // this error will actually be referring to the same error code! case class OtherError(otherContext: Val) extends BaseError with SyncServiceError } } object HandshakeErrors extends ErrorGroup { ... } }

11.  abstract class ErrorGroup extends AnyRef
12.  trait ErrorResource extends AnyRef

    Type of error resource

    Type of error resource

    Some errors are linked to a specific resource such as a contract id or a package id. In such cases, we include the resource identifier as part of the error message. This enum allows an error to provide identifiers of a resource

13.  final case class Explanation(explanation: String) extends Annotation with StaticAnnotation with Product with Serializable
14.  final case class Grouping(docName: String, fullClassName: String) extends Product with Serializable

    A component of ErrorClass

    A component of ErrorClass

    docName

    The name that will appear in the generated documentation for the grouping.

    fullClassName

    Full class name of the corresponding ErrorGroup.

15.  trait LocationMixin extends AnyRef
16.  class NoLogging extends ContextualizedErrorLogger
17.  final case class Resolution(resolution: String) extends Annotation with StaticAnnotation with Product with Serializable
18.  final case class RetryStrategy(retryStrategy: String) extends Annotation with StaticAnnotation with Product with Serializable