Mobile Error Handling
Purpose
Plan resilient error handling: React error boundaries, consistent async/network error handling, graceful fallback UI, and crash/error reporting.
When to Use
- When building screens/flows that can fail (network, native, parsing).
- Not as a substitute for fixing root-cause bugs (
../../bug-investigation).
Inputs
- The failure surfaces (network, native, render, parse).
- Reporting tool choice (e.g. Sentry) and environment config.
Discovery Questions
- Where can this flow fail, and how should it degrade?
- What user-facing fallback is appropriate per failure?
- Is crash/error reporting (Sentry) used, and how is PII handled?
- How are network/async errors surfaced consistently?
Responsibilities
- Add error boundaries around risky subtrees with fallback UI.
- Handle async/network errors consistently (retry/surface).
- Provide graceful fallback UX (not blank/crash).
- Wire crash/error reporting (e.g. Sentry) with PII care (
../../security-review).
Required Workflow
- Map failure surfaces.
- Add boundaries + fallback UI.
- Standardize async/network error handling.
- Wire reporting with PII scrubbing.
- Record the error-handling plan.
Decision Rules
- Fail gracefully with a fallback; never blank-screen or crash the app on a handled error.
- Report crashes/errors, but scrub PII/secrets from reports.
- Consistent error surfacing beats per-screen ad-hoc handling.
- Errors don't leak internal details to users.
Rules
- No PII/secrets in error reports or logs (
mobile-logging, ../../security-review).
- Consistent, user-friendly error surfacing.
- Coordinate with server-state error mapping.
Anti-Patterns
- Crashing/blank-screening on handled errors.
- Leaking stack traces/internal details to users.
- Sending PII to the crash reporter.
- Ad-hoc, inconsistent error handling.
Validation Checklist
Definition of Done
A recorded error-handling plan: boundaries with fallback UI, consistent async/network handling, and PII-safe crash/error reporting — failures degrade gracefully and are observed.
Related Skills
mobile-logging, mobile-server-state, mobile-api-integration, ../../security-review, ../../bug-investigation
Related Knowledge
../../../knowledge/ (failure modes).
Related References
../../../references/mobile/screens/ when populated.
Context Loading Guidance
- Requires: failure surfaces, reporting tool, env config.
- Does not require: unrelated screens, the full mobile skill set, unrelated references.
- May load:
mobile-logging, ../../security-review.
- Stop when: the error-handling plan is recorded.
Token Efficiency Guidance
Plan boundaries + reporting for the flow in scope; delegate logging/PII rules to their skills.
1---2name: mobile-error-handling3description: Use to plan error handling — error boundaries, async/network error handling, user-facing fallback UI, and crash reporting (e.g. Sentry) — so failures degrade gracefully and are observed.4---56# Mobile Error Handling78## Purpose910Plan resilient error handling: React error boundaries, consistent async/network error handling, graceful fallback UI, and crash/error reporting.1112## When to Use1314- When building screens/flows that can fail (network, native, parsing).15- Not as a substitute for fixing root-cause bugs (`../../bug-investigation`).1617## Inputs1819- The failure surfaces (network, native, render, parse).20- Reporting tool choice (e.g. Sentry) and environment config.2122## Discovery Questions2324- Where can this flow fail, and how should it degrade?25- What user-facing fallback is appropriate per failure?26- Is crash/error reporting (Sentry) used, and how is PII handled?27- How are network/async errors surfaced consistently?2829## Responsibilities3031- Add **error boundaries** around risky subtrees with fallback UI.32- Handle **async/network errors** consistently (retry/surface).33- Provide **graceful fallback UX** (not blank/crash).34- Wire **crash/error reporting** (e.g. Sentry) with PII care (`../../security-review`).3536## Required Workflow37381. Map failure surfaces.392. Add boundaries + fallback UI.403. Standardize async/network error handling.414. Wire reporting with PII scrubbing.425. Record the error-handling plan.4344## Decision Rules4546- Fail gracefully with a fallback; never blank-screen or crash the app on a handled error.47- Report crashes/errors, but scrub PII/secrets from reports.48- Consistent error surfacing beats per-screen ad-hoc handling.49- Errors don't leak internal details to users.5051## Rules5253- No PII/secrets in error reports or logs (`mobile-logging`, `../../security-review`).54- Consistent, user-friendly error surfacing.55- Coordinate with server-state error mapping.5657## Anti-Patterns5859- Crashing/blank-screening on handled errors.60- Leaking stack traces/internal details to users.61- Sending PII to the crash reporter.62- Ad-hoc, inconsistent error handling.6364## Validation Checklist6566- [ ] Failure surfaces mapped.67- [ ] Error boundaries + fallback UI in place.68- [ ] Async/network errors handled consistently.69- [ ] Reporting wired with PII scrubbing.70- [ ] No internal details leaked to users.7172## Definition of Done7374A recorded error-handling plan: boundaries with fallback UI, consistent async/network handling, and PII-safe crash/error reporting — failures degrade gracefully and are observed.7576## Related Skills7778`mobile-logging`, `mobile-server-state`, `mobile-api-integration`, `../../security-review`, `../../bug-investigation`7980## Related Knowledge8182`../../../knowledge/` (failure modes).8384## Related References8586`../../../references/mobile/screens/` when populated.8788## Context Loading Guidance8990- **Requires:** failure surfaces, reporting tool, env config.91- **Does not require:** unrelated screens, the full mobile skill set, unrelated references.92- **May load:** `mobile-logging`, `../../security-review`.93- **Stop when:** the error-handling plan is recorded.9495## Token Efficiency Guidance9697Plan boundaries + reporting for the flow in scope; delegate logging/PII rules to their skills.
ahtishamshahzad