error-handling-patterns

Name: error-handling-patterns
Author: wshobson

18kinstalls4.1kforks

How to install error-handling-patterns?

wshobson/agents/error-handling-patterns

$npx -y skills add wshobson/agents --skill error-handling-patterns

Installs into the current project.

Summary

Master error handling patterns across languages including exceptions, Result types, error propagation, and graceful degradation to build resilient applications. Use when implementing error handling, designing APIs, or improving application reliability.

Files · 1

View on GitHub

SKILL.md

1	# Error Handling Patterns
2
3	Build resilient applications with robust error handling strategies that gracefully handle failures and provide excellent debugging experiences.
4
5	## When to Use This Skill
6
7	- Implementing error handling in new features
8	- Designing error-resilient APIs
9	- Debugging production issues
10	- Improving application reliability
11	- Creating better error messages for users and developers
12	- Implementing retry and circuit breaker patterns
13	- Handling async/concurrent errors
14	- Building fault-tolerant distributed systems
15
16	## Core Concepts
17
18	### 1. Error Handling Philosophies
19
20	Exceptions vs Result Types:
21
22	- Exceptions: Traditional try-catch, disrupts control flow
23	- Result Types: Explicit success/failure, functional approach
24	- Error Codes: C-style, requires discipline
25	- Option/Maybe Types: For nullable values
26
27	When to Use Each:
28
29	- Exceptions: Unexpected errors, exceptional conditions
30	- Result Types: Expected errors, validation failures
31	- Panics/Crashes: Unrecoverable errors, programming bugs
32
33	### 2. Error Categories
34
35	Recoverable Errors:
36
37	- Network timeouts
38	- Missing files
39	- Invalid user input
40	- API rate limits
41
42	Unrecoverable Errors:
43
44	- Out of memory
45	- Stack overflow
46	- Programming bugs (null pointer, etc.)
47
48	## Detailed patterns and worked examples
49
50	Detailed pattern documentation lives in `references/details.md`. Read that file when the navigation tier above is insufficient.
51
52	## Best Practices
53
54	1. Fail Fast: Validate input early, fail quickly
55	2. Preserve Context: Include stack traces, metadata, timestamps
56	3. Meaningful Messages: Explain what happened and how to fix it
57	4. Log Appropriately: Error = log, expected failure = don't spam logs
58	5. Handle at Right Level: Catch where you can meaningfully handle
59	6. Clean Up Resources: Use try-finally, context managers, defer
60	7. Don't Swallow Errors: Log or re-throw, don't silently ignore
61	8. Type-Safe Errors: Use typed errors when possible
62
63	```python
64	# Good error handling example
65	def process_order(order_id: str) -> Order:
66	"""Process order with comprehensive error handling."""
67	try:
68	# Validate input
69	if not order_id:
70	raise ValidationError("Order ID is required")
71
72	# Fetch order
73	order = db.get_order(order_id)
74	if not order:
75	raise NotFoundError("Order", order_id)
76
77	# Process payment
78	try:
79	payment_result = payment_service.charge(order.total)
80	except PaymentServiceError as e:
81	# Log and wrap external service error
82	logger.error(f"Payment failed for order {order_id}: {e}")
83	raise ExternalServiceError(
84	f"Payment processing failed",
85	service="payment_service",
86	details={"order_id": order_id, "amount": order.total}
87	) from e
88
89	# Update order
90	order.status = "completed"
91	order.payment_id = payment_result.id
92	db.save(order)
93
94	return order
95
96	except ApplicationError:
97	# Re-raise known application errors
98	raise
99	except Exception as e:
100	# Log unexpected errors
101	logger.exception(f"Unexpected error processing order {order_id}")
102	raise ApplicationError(
103	"Order processing failed",
104	code="INTERNAL_ERROR"
105	) from e
106	```
107
108	## Common Pitfalls
109
110	- Catching Too Broadly: `except Exception` hides bugs
111	- Empty Catch Blocks: Silently swallowing errors
112	- Logging and Re-throwing: Creates duplicate log entries
113	- Not Cleaning Up: Forgetting to close files, connections
114	- Poor Error Messages: "Error occurred" is not helpful
115	- Returning Error Codes: Use exceptions or Result types
116	- Ignoring Async Errors: Unhandled promise rejections

People who liked this also viewed

6 picks

Type

error-handling-patterns

18kinstalls4.1kforks

View on GitHub

How to install error-handling-patterns?

wshobson/agents/error-handling-patterns

$npx -y skills add wshobson/agents --skill error-handling-patterns

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Error Handling Patterns
2
3	Build resilient applications with robust error handling strategies that gracefully handle failures and provide excellent debugging experiences.
4
5	## When to Use This Skill
6
7	- Implementing error handling in new features
8	- Designing error-resilient APIs
9	- Debugging production issues
10	- Improving application reliability
11	- Creating better error messages for users and developers
12	- Implementing retry and circuit breaker patterns
13	- Handling async/concurrent errors
14	- Building fault-tolerant distributed systems
15
16	## Core Concepts
17
18	### 1. Error Handling Philosophies
19
20	Exceptions vs Result Types:
21
22	- Exceptions: Traditional try-catch, disrupts control flow
23	- Result Types: Explicit success/failure, functional approach
24	- Error Codes: C-style, requires discipline
25	- Option/Maybe Types: For nullable values
26
27	When to Use Each:
28
29	- Exceptions: Unexpected errors, exceptional conditions
30	- Result Types: Expected errors, validation failures
31	- Panics/Crashes: Unrecoverable errors, programming bugs
32
33	### 2. Error Categories
34
35	Recoverable Errors:
36
37	- Network timeouts
38	- Missing files
39	- Invalid user input
40	- API rate limits
41
42	Unrecoverable Errors:
43
44	- Out of memory
45	- Stack overflow
46	- Programming bugs (null pointer, etc.)
47
48	## Detailed patterns and worked examples
49
50	Detailed pattern documentation lives in `references/details.md`. Read that file when the navigation tier above is insufficient.
51
52	## Best Practices
53
54	1. Fail Fast: Validate input early, fail quickly
55	2. Preserve Context: Include stack traces, metadata, timestamps
56	3. Meaningful Messages: Explain what happened and how to fix it
57	4. Log Appropriately: Error = log, expected failure = don't spam logs
58	5. Handle at Right Level: Catch where you can meaningfully handle
59	6. Clean Up Resources: Use try-finally, context managers, defer
60	7. Don't Swallow Errors: Log or re-throw, don't silently ignore
61	8. Type-Safe Errors: Use typed errors when possible
62
63	```python
64	# Good error handling example
65	def process_order(order_id: str) -> Order:
66	"""Process order with comprehensive error handling."""
67	try:
68	# Validate input
69	if not order_id:
70	raise ValidationError("Order ID is required")
71
72	# Fetch order
73	order = db.get_order(order_id)
74	if not order:
75	raise NotFoundError("Order", order_id)
76
77	# Process payment
78	try:
79	payment_result = payment_service.charge(order.total)
80	except PaymentServiceError as e:
81	# Log and wrap external service error
82	logger.error(f"Payment failed for order {order_id}: {e}")
83	raise ExternalServiceError(
84	f"Payment processing failed",
85	service="payment_service",
86	details={"order_id": order_id, "amount": order.total}
87	) from e
88
89	# Update order
90	order.status = "completed"
91	order.payment_id = payment_result.id
92	db.save(order)
93
94	return order
95
96	except ApplicationError:
97	# Re-raise known application errors
98	raise
99	except Exception as e:
100	# Log unexpected errors
101	logger.exception(f"Unexpected error processing order {order_id}")
102	raise ApplicationError(
103	"Order processing failed",
104	code="INTERNAL_ERROR"
105	) from e
106	```
107
108	## Common Pitfalls
109
110	- Catching Too Broadly: `except Exception` hides bugs
111	- Empty Catch Blocks: Silently swallowing errors
112	- Logging and Re-throwing: Creates duplicate log entries
113	- Not Cleaning Up: Forgetting to close files, connections
114	- Poor Error Messages: "Error occurred" is not helpful
115	- Returning Error Codes: Use exceptions or Result types
116	- Ignoring Async Errors: Unhandled promise rejections

People who liked this also viewed

6 picks

Type