Skip to main content

ValidationError

ValidationError is the standard error type thrown when validation fails. It contains structured information about all validation issues.

ValidationError API

Properties

Methods

getMessages()

Get all error messages as a flat array:

getFormattedErrors()

Get errors formatted for UI/API consumption:
Use this for form field bindings. The path is a dot-joined string (empty string for global errors).

getErrorsForPath(path)

Get errors for a specific field:

hasErrorsForPath(path)

Check if a field has errors:

toJSON()

Serialize for API responses:

Static Methods

isValidationError(error)

Type-safe check that works across module boundaries:
Always use ValidationError.isValidationError() instead of instanceof for reliable detection across module boundaries.

Throwing Validation Errors

In Hooks

Use the throwValidationError helper:

Manually

Create and throw directly:

Non-Throwing Mode

Configure entities to collect errors instead of throwing:

Collecting Issues in rules (without throwing)

When throwOnError is false, use addValidationIssue inside rules to accumulate business rule violations:
Issues from schema validation and addValidationIssue are merged into validationErrors. Use throwValidationError when you want fail-fast behavior (always throws, regardless of throwOnError).

persistInvalidMutations

When throwOnError is false, this flag defines whether invalid updates are kept on the entity:
persistInvalidMutations: true (default)
  • Property changes apply even when schema or rules fail.
  • validationErrors reflects the latest validation of the current props (all fields).
  • Matches form UX: what the user typed is what toJSON() returns.
persistInvalidMutations: false
  • While validationErrors exists, further mutations are blocked (including delete).
  • A single update that fails validation is reverted; errors are still recorded.
Before save() or exporting changes, validate !entity.hasValidationErrors when using dirty mode.

When to Use Non-Throwing Mode

Form Validation

Collect all errors to display to user at once

Import/Migration

Log errors but continue processing

Partial Validation

Allow incomplete entities during construction

Error Aggregation

Combine errors from multiple sources

API Error Responses

Express.js Example

Response Format


Domain Exceptions

Beyond ValidationError, rich-domain provides a comprehensive set of domain exceptions for different error scenarios. All exceptions extend a common DomainException base class.

Exception Hierarchy

Common Properties

All domain exceptions share these properties:

Entity & Aggregate Exceptions

DomainError

General-purpose exception for business rule violations:

EntityNotFoundError

When an entity or aggregate cannot be found:

EntityAlreadyExistsError

When trying to create an entity that already exists:

Repository & Persistence Exceptions

RepositoryError

Base exception for repository operations:

PersistenceError

When a database operation fails:

ConcurrencyError

For optimistic locking conflicts:

ConstraintViolationError

When a database constraint is violated:

Other Exceptions

InvalidValueObjectError

When a Value Object receives invalid data, it throws automatically with schema validation:

InvalidCriteriaError

When a Criteria query is invalid:

TransactionError

When a transaction operation fails:

MapperError

When mapping between domain and persistence fails:

DomainEventError & EventHandlerError

For event-related failures:

Utility Exceptions


Handling Domain Exceptions

Centralized Error Handler

Exception Reference Table