Error Handling Review Skill

Error Handling Review Skill

Purpose

Ensure every data-driven UI and action has correct, user-useful handling for loading, error, empty, success, retry, and fallback states — without hiding real problems behind generic fallbacks.

When to Use

• After connecting UI to data/APIs (see Connect Data and API Skill).
• Reviewing a feature/screen for completeness before handoff or launch.
• Investigating a bug related to missing or incorrect state handling.

When Not to Use

• Static, non-data-driven UI with no async operations.
• The states have already been reviewed and nothing changed since.

Required Inputs

• The screen/feature and its data operations (reads, writes, async actions).
• Existing patterns for loading/error/empty UI in the project (spinners, skeletons, error banners, empty-state components).

Assumptions

• Every async data operation the UI depends on should have defined loading, error, empty (if applicable), and success states.
• Errors should be surfaced to the user in a useful way, not hidden or generically swallowed.

Step-by-Step Workflow

1. List all async operations on the screen/feature: data fetches, mutations (create/update/delete), file uploads, etc.
2. For each operation, check:
   • Loading: is there a visible loading indicator (spinner/skeleton) while the operation is in progress? Does it avoid layout jumps where reasonable?
   • Error: if the operation fails, does the user see a clear message (per Write Product Text Skill)? Is there a retry option where retrying makes sense?
   • Empty: if the operation succeeds but returns no data, is there a distinct empty state (not just a blank area)?
   • Success: does the UI update correctly to reflect the new state (e.g. list updates after creation, confirmation shown after save)?
   • Fallback: for non-critical optional data (e.g. an avatar image, an optional widget), is there a sensible fallback that doesn't break the page if it fails?
3. Check error propagation: errors from the data layer should reach the UI layer (not be swallowed in a service/hook with an empty catch).
4. Check retry behavior: retries should be available where the user can reasonably resolve the issue (e.g. network blip) and should not retry indefinitely or spam the backend.
5. Check for "infinite loading": ensure loading states have a defined end condition (success, error, or timeout) — no states that can hang forever without feedback.
6. Check for fake/placeholder success: confirm success states only show when the operation actually completed, not optimistically faked without real confirmation (unless the project intentionally uses optimistic updates with rollback on failure).

Rules and Best Practices

• Every user-triggered async action should give feedback: in progress, succeeded, or failed.
• Error messages should be specific enough to be useful (see Write Product Text Skill) — avoid only "Something went wrong" when more specific info is available.
• Don't use broad try/catch blocks that swallow errors without surfacing or logging them.
• Empty states should be distinguishable from loading and error states.