|
| 1 | +# Error Handling Standards for Server Functions |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +This document defines the standard error handling patterns for all server-side API functions in the codebase. |
| 6 | + |
| 7 | +## Core Principles |
| 8 | + |
| 9 | +1. **User feedback comes from the UI layer** - Server functions focus on data retrieval/mutation |
| 10 | +2. **Consistent patterns** - Similar operations should handle errors the same way |
| 11 | +3. **Graceful degradation** - Read operations should fail gracefully with empty data |
| 12 | +4. **Clear failure signals** - Write operations should throw errors for the UI to catch |
| 13 | + |
| 14 | +--- |
| 15 | + |
| 16 | +## Standard Patterns |
| 17 | + |
| 18 | +### Pattern A: Read Operations (GET) |
| 19 | + |
| 20 | +**Use for:** Fetching data, list operations, queries |
| 21 | + |
| 22 | +```typescript |
| 23 | +export async function getData(id: string): Promise<Data[]> { |
| 24 | + const result = await fetchApi<Data[]>(`/endpoint/${id}`); |
| 25 | + |
| 26 | + // Return empty array/null on failure - UI will show "no data" state |
| 27 | + if (!result) { |
| 28 | + return []; // or null for single items |
| 29 | + } |
| 30 | + |
| 31 | + return result; |
| 32 | +} |
| 33 | +``` |
| 34 | + |
| 35 | +**Why:** |
| 36 | + |
| 37 | +- Users can still use the app even if one data source fails |
| 38 | +- UI naturally shows "no data" or "empty" states |
| 39 | +- Errors are already logged by `fetchApi` |
| 40 | + |
| 41 | +### Pattern B: Write Operations (POST/PUT/PATCH/DELETE) |
| 42 | + |
| 43 | +**Use for:** Creating, updating, deleting data |
| 44 | + |
| 45 | +```typescript |
| 46 | +export async function createData(data: Data): Promise<Data> { |
| 47 | + const result = await fetchApi<Data>("/endpoint", { |
| 48 | + method: "POST", |
| 49 | + body: JSON.stringify(data), |
| 50 | + }); |
| 51 | + |
| 52 | + // Throw error - UI will catch and show toast/error message |
| 53 | + if (!result) { |
| 54 | + throw new Error("Failed to create data"); |
| 55 | + } |
| 56 | + |
| 57 | + return result; |
| 58 | +} |
| 59 | +``` |
| 60 | + |
| 61 | +**Why:** |
| 62 | + |
| 63 | +- Write operations are user-initiated actions that need feedback |
| 64 | +- UI layer can catch the error and show appropriate toast/modal |
| 65 | +- Clear signal that the operation failed |
| 66 | + |
| 67 | +### Pattern C: Critical Read Operations |
| 68 | + |
| 69 | +**Use for:** Data required for the page to function (rare) |
| 70 | + |
| 71 | +```typescript |
| 72 | +export async function getCriticalData(id: string): Promise<Data> { |
| 73 | + const result = await fetchApi<Data>(`/critical/${id}`); |
| 74 | + |
| 75 | + if (!result) { |
| 76 | + throw new Error("Failed to load required data"); |
| 77 | + } |
| 78 | + |
| 79 | + return result; |
| 80 | +} |
| 81 | +``` |
| 82 | + |
| 83 | +**Why:** |
| 84 | + |
| 85 | +- Some data is essential for the page to work |
| 86 | +- UI can show error boundary or redirect |
| 87 | + |
| 88 | +--- |
| 89 | + |
| 90 | +## Migration Guide |
| 91 | + |
| 92 | +### ❌ Avoid Try-Catch in Server Functions |
| 93 | + |
| 94 | +```typescript |
| 95 | +// DON'T DO THIS - fetchApi already handles errors |
| 96 | +try { |
| 97 | + const result = await fetchApi<T>(endpoint); |
| 98 | + return result || []; |
| 99 | +} catch (error) { |
| 100 | + console.error(error); |
| 101 | + return []; |
| 102 | +} |
| 103 | +``` |
| 104 | + |
| 105 | +```typescript |
| 106 | +// DO THIS - Let fetchApi handle errors, check result |
| 107 | +const result = await fetchApi<T>(endpoint); |
| 108 | +return result || []; |
| 109 | +``` |
| 110 | + |
| 111 | +### UI Layer Responsibilities |
| 112 | + |
| 113 | +The UI components should handle errors from write operations: |
| 114 | + |
| 115 | +```typescript |
| 116 | +// In React component |
| 117 | +const handleCreate = async () => { |
| 118 | + try { |
| 119 | + await createData(formData); |
| 120 | + toast.success("Created successfully"); |
| 121 | + } catch (error) { |
| 122 | + toast.error(error.message || "Failed to create"); |
| 123 | + } |
| 124 | +}; |
| 125 | +``` |
| 126 | + |
| 127 | +--- |
| 128 | + |
| 129 | +## Examples by Function Type |
| 130 | + |
| 131 | +| Function Type | Pattern | Return on Error | Example | |
| 132 | +| -------------------- | ------- | --------------- | ------------------ | |
| 133 | +| `getProjects()` | A | `[]` | List of projects | |
| 134 | +| `getOneProject()` | A | `null` | Single project | |
| 135 | +| `createProject()` | B | `throw` | Create new project | |
| 136 | +| `updateProject()` | B | `throw` | Update project | |
| 137 | +| `deleteProject()` | B | `void` (throws) | Delete project | |
| 138 | +| `getOrganizations()` | A | `[]` | List of orgs | |
| 139 | +| `getUserProfile()` | C | `throw` | Required for auth | |
| 140 | + |
| 141 | +--- |
| 142 | + |
| 143 | +## Decision Tree |
| 144 | + |
| 145 | +``` |
| 146 | +Is this a READ operation? |
| 147 | +├─ Yes: Is the data critical for the page? |
| 148 | +│ ├─ Yes: Use Pattern C (throw) |
| 149 | +│ └─ No: Use Pattern A (return empty) |
| 150 | +└─ No (WRITE operation): Use Pattern B (throw) |
| 151 | +``` |
0 commit comments