error-handling

Name: error-handling
Author: DevelopersGlobal

64stars10forks

How to install error-handling?

developersglobal/ai-agent-skills/error-handling

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill error-handling

Installs into the current project.

Summary

Graceful degradation and meaningful error messages. Errors are first-class citizens, not afterthoughts. Every error path is designed, not discovered.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	Error handling is not defensive programming — it's a user experience. When things go wrong (and they will), the system should degrade gracefully, give users actionable information, and leave enough telemetry to diagnose and fix the problem.
4
5	## When to Use
6
7	- When writing any code that can fail (I/O, network, parsing, user input)
8	- When reviewing error handling in existing code
9	- Before any service goes to production
10
11	## Process
12
13	### Step 1: Design Error Paths Explicitly
14
15	1. For every operation, list: what can fail? What does failure look like?
16	2. Classify failures:
17	- Transient: Retry likely to succeed (network blip, temporary unavailability)
18	- Client error: Bad input from the caller (4xx) — don't retry
19	- System error: Internal failure (5xx) — alert, investigate
20	3. Design the failure path for each class before writing the happy path.
21
22	Verify: Error classes defined for every external operation.
23
24	### Step 2: Meaningful Error Messages
25
26	4. Every error message answers: what went wrong? How can the caller fix it?
27	- ✅ "Invalid email format. Expected: user@domain.com"
28	- ❌ "Validation error"
29	5. User-facing errors: friendly language, no stack traces.
30	6. Developer-facing errors (logs): full context, request ID, stack trace.
31	7. Never expose internal system details (DB schema, file paths) in user-facing errors.
32
33	Verify: Each error message would help a user or developer understand and fix the problem.
34
35	### Step 3: Retry with Backoff
36
37	8. Transient errors: retry with exponential backoff + jitter.
38	9. Maximum retries: 3 (not infinite).
39	10. After max retries: fail with a clear error, log the final failure.
40	11. Non-transient errors (validation, auth): never retry.
41
42	Verify: Retry logic has a maximum. Non-transient errors don't retry.
43
44	### Step 4: Graceful Degradation
45
46	12. Identify non-critical dependencies. If they fail, degrade — don't crash.
47	13. Example: recommendation engine fails → show default content, not 500.
48	14. Circuit breaker pattern for failing dependencies: fail fast after threshold, recover automatically.
49
50	Verify: Every non-critical dependency has a defined degraded state.
51
52	### Step 5: Structured Error Responses (APIs)
53
54	15. API errors return consistent structure:
55	```json
56	{
57	"error": {
58	"code": "INVALID_EMAIL",
59	"message": "The email address format is invalid.",
60	"requestId": "req_abc123"
61	}
62	}
63	```
64	16. HTTP status codes used correctly: 400 (client error), 404 (not found), 429 (rate limited), 500 (server error).
65
66	## Common Rationalizations (and Rebuttals)
67
68	\| Excuse \| Rebuttal \|
69	\|--------\|----------\|
70	\| "I'll add error handling later" \| Later means in production, under pressure, while users are impacted. \|
71	\| "This can't fail" \| Everything can fail. Network calls, disk writes, parsing — all can fail. \|
72	\| "The error message doesn't matter" \| It matters when a developer is debugging at 2am. \|
73
74	## Verification
75
76	- [ ] Error classes defined for every external operation
77	- [ ] Error messages answer: what went wrong? How to fix?
78	- [ ] Transient errors retry with max limit
79	- [ ] Non-critical dependencies have graceful degraded states
80	- [ ] API errors return consistent structured format
81	- [ ] No internal system details in user-facing errors
82
83	## References
84
85	- [observability skill](../observability/SKILL.md)
86	- [debugging-methodology skill](../debugging-methodology/SKILL.md)

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

error-handling

64stars10forks

View on GitHub

How to install error-handling?

developersglobal/ai-agent-skills/error-handling

$npx -y skills add DevelopersGlobal/ai-agent-skills --skill error-handling

Installs into the current project.

Summary

Graceful degradation and meaningful error messages. Errors are first-class citizens, not afterthoughts. Every error path is designed, not discovered.

Files · 1

View on GitHub

SKILL.md

1	## Overview
2
3	Error handling is not defensive programming — it's a user experience. When things go wrong (and they will), the system should degrade gracefully, give users actionable information, and leave enough telemetry to diagnose and fix the problem.
4
5	## When to Use
6
7	- When writing any code that can fail (I/O, network, parsing, user input)
8	- When reviewing error handling in existing code
9	- Before any service goes to production
10
11	## Process
12
13	### Step 1: Design Error Paths Explicitly
14
15	1. For every operation, list: what can fail? What does failure look like?
16	2. Classify failures:
17	- Transient: Retry likely to succeed (network blip, temporary unavailability)
18	- Client error: Bad input from the caller (4xx) — don't retry
19	- System error: Internal failure (5xx) — alert, investigate
20	3. Design the failure path for each class before writing the happy path.
21
22	Verify: Error classes defined for every external operation.
23
24	### Step 2: Meaningful Error Messages
25
26	4. Every error message answers: what went wrong? How can the caller fix it?
27	- ✅ "Invalid email format. Expected: user@domain.com"
28	- ❌ "Validation error"
29	5. User-facing errors: friendly language, no stack traces.
30	6. Developer-facing errors (logs): full context, request ID, stack trace.
31	7. Never expose internal system details (DB schema, file paths) in user-facing errors.
32
33	Verify: Each error message would help a user or developer understand and fix the problem.
34
35	### Step 3: Retry with Backoff
36
37	8. Transient errors: retry with exponential backoff + jitter.
38	9. Maximum retries: 3 (not infinite).
39	10. After max retries: fail with a clear error, log the final failure.
40	11. Non-transient errors (validation, auth): never retry.
41
42	Verify: Retry logic has a maximum. Non-transient errors don't retry.
43
44	### Step 4: Graceful Degradation
45
46	12. Identify non-critical dependencies. If they fail, degrade — don't crash.
47	13. Example: recommendation engine fails → show default content, not 500.
48	14. Circuit breaker pattern for failing dependencies: fail fast after threshold, recover automatically.
49
50	Verify: Every non-critical dependency has a defined degraded state.
51
52	### Step 5: Structured Error Responses (APIs)
53
54	15. API errors return consistent structure:
55	```json
56	{
57	"error": {
58	"code": "INVALID_EMAIL",
59	"message": "The email address format is invalid.",
60	"requestId": "req_abc123"
61	}
62	}
63	```
64	16. HTTP status codes used correctly: 400 (client error), 404 (not found), 429 (rate limited), 500 (server error).
65
66	## Common Rationalizations (and Rebuttals)
67
68	\| Excuse \| Rebuttal \|
69	\|--------\|----------\|
70	\| "I'll add error handling later" \| Later means in production, under pressure, while users are impacted. \|
71	\| "This can't fail" \| Everything can fail. Network calls, disk writes, parsing — all can fail. \|
72	\| "The error message doesn't matter" \| It matters when a developer is debugging at 2am. \|
73
74	## Verification
75
76	- [ ] Error classes defined for every external operation
77	- [ ] Error messages answer: what went wrong? How to fix?
78	- [ ] Transient errors retry with max limit
79	- [ ] Non-critical dependencies have graceful degraded states
80	- [ ] API errors return consistent structured format
81	- [ ] No internal system details in user-facing errors
82
83	## References
84
85	- [observability skill](../observability/SKILL.md)
86	- [debugging-methodology skill](../debugging-methodology/SKILL.md)

People who liked this also viewed

6 picks

Type