Error Handling
Priority: P1 (HIGH)
Implementation Workflow
- Define failures — Create domain-specific failures using
@freezedunions (e.g.,UnauthorizedFailure,OutOfStockFailure). - Return Either — Repositories return
Either<Failure, T>. No exceptions in UI/BLoC. - Catch in Infrastructure only — Infrastructure catches exceptions (e.g.,
DioException) and returnsLeft(Failure). Never rethrow to UI. - Fold in BLoC — Use
.fold(failure, success)in BLoC to emit corresponding states. Remove try/catch from BLoC. - Localize messages — Use
failure.failureMessage(returnsTRObjector localized string) for UI-safe text. - Log with stable templates — Use low-cardinality message templates; pass variable data via metadata/context.
- No Silent Catch: Never swallow errors without logging or documented retry.
- Crashlytics Routing: All UI/BLoC
catchblocks MUST route errors viaAppLogger.error(AppException.fromException(e).message, error: e, stackTrace: st)for observability and type-safe UI messages.
Repository & BLoC Examples
See implementation examples for repository error mapping and BLoC consumption patterns.
Reference & Examples
For Failure definitions and API error mapping: See references/REFERENCE.md.
Anti-Patterns
- No Try-Catch in BLoC: BLoC receives
Eitherandfolds; try/catch belongs in Infrastructure - No Plain String Failures: Define typed
@freezedFailure subclasses instead ofLeft('Something went wrong') - No Empty Catch Blocks: Always log and propagate; never swallow errors silently
- No Repositories Throwing Status: Return
Left(Failure)instead of throwingException - No Missing Log Registration: Use
AppLogger.errorin BLoC/UIcatchto ensure Crashlytics tracking and type-safe UI messages
Related Topics
layer-based-clean-architecture | bloc-state-management