error-handling-patterns_skill

Overview

This skill provides expert guidance on error handling decisions for iOS and tvOS projects. It helps choose between throws and Result, design actionable error types, select recovery strategies, and pick user-facing presentation patterns. Use it to make trade-offs that improve reliability, observability, and UX.

How this skill works

The skill evaluates context (caller expectations, failure frequency, API boundaries) and recommends patterns: Result when failures are expected and must be handled, throws for exceptional failures, and try?/try! for cases where failure is acceptable or impossible. It also prescribes error granularity, retry policies (idempotency and backoff), and presentation strategies (toast, alert, full-screen). It flags common mistakes like swallowing errors, leaking sensitive info, retrying non-idempotent operations, and exposing CancellationError to users.

When to use it

• Designing library or framework error APIs and deciding how coarse/fine-grained errors should be
• Choosing between throws, Result, try?, and try! for a given API or call site
• Implementing retry logic with exponential backoff and idempotency keys
• Mapping internal errors to user-facing messages and recovery suggestions
• Creating ViewModel error states and deciding when to show vs log errors

Best practices

• Use Result<T,E> for validation and parsing where failure is expected and must be handled explicitly
• Use throws for exceptional I/O and network errors to keep call sites clean with async/await
• Design error enums to be actionable; collapse cases if handlers are identical
• Never include sensitive data in error associated values or logs; sanitize before throwing
• Treat CancellationError specially—don’t surface it to the user
• Retry only idempotent or safe operations, with limited attempts and exponential backoff

Example use cases

• API client: expose coarse NetworkError across framework boundaries and map to LocalizedError for UI
• Form validation: return Result to force exhaustive handling at the caller and show inline errors
• Payment processing: use idempotency keys and cautious retries for non-idempotent operations
• ViewModel load flows: translate domain errors into state with user message and isRetryable flag
• Background sync: log failures silently and use fallback values when user does not need to know