Skip to main content
Cindel uses specific, named error types so you can respond precisely to actionable conditions — distinguishing a duplicate-key violation from a storage failure from a programming mistake — rather than catching a generic exception and guessing what went wrong. All Cindel-specific runtime errors extend StateError and share the CindelError base class. Catch the most specific type you can, and let everything else surface to your normal error-reporting pipeline.
CindelOpenError is thrown when the database backend cannot be opened. You will encounter this error at startup, inside your Cindel.open(...) call, never during normal query or write operations.Common causes
  • The directory path does not exist or is invalid
  • The application does not have write permission for that directory
  • A required platform dependency is missing
  • On Web: the browser does not support the required storage features (OPFS/SQLite Web), private-browsing mode is active, or the storage quota has been exceeded
RecoveryCheck that the target directory exists and is writable before calling open. On Web, detect storage unavailability early and show a graceful message rather than letting the error propagate silently.
CindelSchemaError is thrown when the schemas you pass at open time don’t match the metadata already stored on disk. Like CindelOpenError, this surfaces during Cindel.open(...).Common causes
  • A required schema is missing from the schemas: list
  • You changed your data model but forgot to re-run build_runner, so the generated code is stale
  • Stored data was written with a different schema version and no migration plan was provided
RecoveryMake sure every schema your database uses is listed in schemas:. After any model change, re-run code generation before opening the database. When stored data must be rewritten to match a new model shape, provide a CindelMigrationPlan.
CindelDatabaseClosedError is thrown when code attempts to use a database instance after close() has already been called on it.Common causes
  • Holding a reference to a database and using it after the owning component has already shut down
  • Calling close() then reusing the same handle instead of reopening
RecoveryMake ownership clear: the component that opens the database decides when it is closed. Avoid sharing a closed database handle. If you need the database again after closing, open a fresh instance.
CindelTransactionError is thrown when an invalid transaction operation is attempted at runtime.Common causes
  • Calling a write operation (e.g. put, delete) inside a readTxn callback
  • Starting nested explicit write transactions
  • Using a transaction object after it is already in an invalid or closed state
RecoveryThis error almost always indicates a structural problem in your code rather than a user-recoverable condition. Use readTxn for read-only work and writeTxn for writes, and keep them separate. If you see this error, restructure the offending code path — don’t catch and suppress it.
CindelQueryError is thrown when a query shape is invalid or unsupported at runtime.Common causes
  • Using a property aggregate (e.g. average()) against a field that holds non-numeric values
  • Applying an unsupported query update shape
  • Composing query helpers in a way that produces an invalid query at runtime
RecoveryUse the generated typed where() and filter() helpers — they are shaped to match your model’s actual field types. When using property aggregates, make sure the target field is numeric.
CindelUniqueIndexError is thrown when an insert or update would violate a unique index — for example, storing two accounts with the same email address.RecoveryCatch this error at the call site where you perform the write and surface a user-friendly message. This is the intended recovery path for natural-key conflicts such as email addresses, usernames, SKUs, or slugs.
If you want duplicate writes to silently replace the existing record instead of failing, annotate the field with @Index(unique: true, replace: true) and use the generated putBy… helper rather than catching this error:
CindelNativeError is thrown when Cindel receives invalid or unexpected native data, or when a native-facing operation returns a result it cannot interpret.RecoveryThis error is not a user-recoverable condition — it indicates a bug or data corruption. Do not catch it to continue silently. Instead, log the error with full context (operation name, relevant IDs, stack trace) and report it so you can investigate and fix the root cause.

General Handling Strategy

Catch specific errors at the point in your code where you can act on them. Handle open and schema errors during startup; handle unique-index errors at individual write call sites.
Avoid broad catch blocks like catch (e) or on CindelError. They hide programming mistakes — such as transaction violations or schema mismatches — that should be fixed in code, not swallowed at runtime. Catch specific error types, and let unhandled errors reach your logging and crash-reporting infrastructure.