Learn

Learn Ark Error Manager

Understand application ownership, typed assessment, ordered processing, sanitization, reporting, presentation, and recovery.

v0.1.0-dev.1Beginner

Learn Ark Error Manager

Ark Error Manager gives an application one place to decide what an exceptional failure means and what the host should do next. It does not replace typed business results, local recovery, or ordinary Dart propagation.

Start with the decision, not the exception

The package is for failures that reach an application boundary and require a coordinated decision. For every caught error, ask these questions in order:

  1. Can this operation recover locally? Recover and return a normal typed result.
  2. Should a caller decide? Transform or rethrow and preserve ordinary propagation.
  3. Has the failure reached an application boundary? Let the configured Zone, Flutter hook, or isolate binding submit it.
  4. Must local code consume the error but still request an application-level action? Submit it deliberately once.
text
Object + StackTrace
        ↓ captured as ErrorOccurrence
Classifier → ErrorAssessment
Context Providers → bounded local facts
Policy → independent report / presentation / recovery decisions
Sanitizer → export-safe ErrorReport
Reporter receives Report; Presenter and Recovery remain application-local

This distinction prevents two common failures: reporting every negative outcome as an incident, and injecting ErrorManager into every feature as a replacement for normal error propagation.

The objects in one incident

ObjectPurposeVisibility
ErrorOccurrenceCaptured error, stack trace, source, and operation metadataApplication-local
ErrorAssessmentTyped category and severityApplication-local
ErrorIncidentOccurrence, assessment, context, and action planPresenter and Recovery
ErrorActionPlanIndependent reporting, presentation, and recovery directivesApplication-local
ErrorReportSanitized export modelReporter boundary
  1. Ownership and boundaries explains why the composition root owns the manager and feature objects do not receive it.
  2. Assessment separates ErrorCategory, ErrorSeverity, and ErrorCaptureSource.
  3. Ordered pipeline follows one occurrence through context, policy, sanitization, reporting, presentation, and recovery.
  4. Choose the correct handling path applies the model to expected outcomes, local recovery, rethrowing, root capture, and deliberate submission.

Continue with a complete Dart or Flutter tutorial, then review Security before adding an external ErrorReporter.

If the terms in the assessment page feel abstract, read the Ordered pipeline next while following the table above. The tutorials then show where each object is created in a running application.

Validation failures, rejected commands, unavailable optional data, and other normal negative outcomes should remain typed results or state. Submit a failure to Ark Error Manager only when it needs an application-level diagnostic, presentation, or recovery decision.

ARKTELOS

Purpose-built engineering systems for software that has to hold.