error-handling-patterns
Mettre en place des schémas robustes de gestion des erreurs
Les applications échouent souvent de manière inattendue en raison d’une mauvaise gestion des erreurs. Cette compétence fournit des schémas éprouvés pour les exceptions, les types Result, les coupe-circuits et la dégradation progressive dans Python, TypeScript, Rust et Go.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "error-handling-patterns". Add error handling to a function that reads a file and parses JSON content.
Résultat attendu:
Here is a pattern for robust file handling with proper error hierarchy:
**Python Example:**
```python
class FileReadError(ApplicationError):
"""Raised when file read operations fail."""
pass
class ParseError(ApplicationError):
"""Raised when JSON parsing fails."""
pass
def read_json_file(path: str) -> dict:
try:
with open(path, 'r') as f:
content = f.read()
return json.loads(content)
except FileNotFoundError as e:
raise FileReadError(f"File not found: {path}", details={"path": path}) from e
except json.JSONDecodeError as e:
raise ParseError(f"Invalid JSON in file: {path}", details={"path": path, "error": str(e)}) from e
```
**Key practices:**
- Use specific exception types for different error scenarios
- Include contextual information in exceptions
- Chain exceptions to preserve original stack trace
- Use context managers for automatic resource cleanup
Utilisation de "error-handling-patterns". How should I handle errors in an async function that calls multiple services in parallel?
Résultat attendu:
For parallel service calls, consider these strategies:
**Option 1: Aggregate Errors**
Collect all errors and report them together rather than failing on the first error.
```typescript
async function fetchUserData(userId: string): Promise<UserData> {
const errors: Error[] = [];
let user: User | null = null;
let orders: Order[] = [];
try { user = await userService.getUser(userId); }
catch (e) { errors.push(e); }
try { orders = await orderService.getOrders(userId); }
catch (e) { errors.push(e); }
if (errors.length > 0) {
throw new AggregateError(errors, `${errors.length} operations failed`);
}
return { user, orders };
}
```
**Option 2: Result Types**
Use explicit success/failure types for each operation.
```typescript
async function fetchUserData(userId: string): Promise<Result<UserData>> {
const [userResult, ordersResult] = await Promise.all([
safePromise(userService.getUser(userId)),
safePromise(orderService.getOrders(userId))
]);
if (!userResult.ok) return Err(userResult.error);
if (!ordersResult.ok) return Err(ordersResult.error);
return Ok({ user: userResult.value, orders: ordersResult.value });
}
```
Utilisation de "error-handling-patterns". What are the worst error handling anti-patterns to avoid?
Résultat attendu:
Here are the most dangerous anti-patterns and their fixes:
**Anti-Pattern 1: Empty Catch Blocks**
```python
try:
do_something()
except:
pass # Silent failure - bugs hide forever
```
**Fix:** Always log or re-raise exceptions.
**Anti-Pattern 2: Catching Too Broadly**
```python
try:
do_something()
except Exception:
# Hides bugs including typos and logic errors
pass
```
**Fix:** Catch specific exception types only.
**Anti-Pattern 3: Swallowing After Logging**
```python
try:
do_something()
except Exception as e:
logger.error(e)
# Error logged but not handled - caller doesn't know it failed
```
**Fix:** Re-raise or return error result.
**Anti-Pattern 4: Overly Generic Errors**
```python
raise Exception("Error occurred") # No context, no code, useless for debugging
```
**Fix:** Include what happened, what was being processed, and error codes.
Audit de sécurité
SûrAll static findings are false positives. The skill is legitimate educational documentation about error handling patterns across Python, TypeScript, Rust, and Go. Static scanner misidentified 'error' keywords as cryptographic issues and Markdown code fences as shell backticks. No actual network calls, command execution, or malicious patterns exist in the skill content.
Score de qualité
Ce que vous pouvez construire
Construire une gestion des erreurs d’API de niveau production
Concevoir la gestion des erreurs pour une nouvelle API REST qui renvoie des réponses d’erreur cohérentes avec les bons codes de statut HTTP, des codes d’erreur et des messages utiles pour les consommateurs d’API.
Ajouter de la résilience aux systèmes distribués
Mettre en œuvre des schémas de coupe-circuit et de retry pour prévenir les défaillances en cascade lorsque des services externes deviennent indisponibles, en veillant à ce que le système se dégrade de manière progressive.
Améliorer les retours de revue de code sur la gestion des erreurs
Fournir des retours spécifiques et actionnables sur la gestion des erreurs dans les pull requests, en identifiant des anti-patterns comme les blocs catch vides ou une gestion des exceptions trop large.
Essayez ces prompts
I need error handling for a {language} function that calls an external API. The function should retry on network failures with exponential backoff, include proper error types, and provide clear error messages for debugging.Design a custom exception hierarchy for a {application_type} application. Include base exception class, specific error types for validation, not found, and external service failures. Each exception should include error code, timestamp, and relevant context.Implement a circuit breaker pattern for a service that makes calls to an unreliable third-party API. Include configuration for failure threshold, timeout duration, and half-open state for recovery testing.
Create a validation system that collects all validation errors rather than failing on the first one. Show how to aggregate errors from multiple fields and return them as a structured response.
Bonnes pratiques
- Créer des types d’exceptions spécifiques avec des informations contextuelles incluant des codes d’erreur, des horodatages et des métadonnées pertinentes pour le débogage
- Utiliser des types Result ou des retours d’erreur explicites pour les échecs attendus afin de rendre la gestion des erreurs obligatoire et visible à la compilation lorsque possible
- Mettre en œuvre des coupe-circuits pour les dépendances externes afin d’éviter les défaillances en cascade et permettre une dégradation progressive
- Journaliser les erreurs avec une sévérité appropriée - niveau error pour les problèmes réels, warning pour les échecs attendus, jamais pour le flux normal
Éviter
- Blocs catch vides qui avalent silencieusement les erreurs, cachent les bugs et rendent le débogage impossible
- Gestionnaires d’exceptions trop larges comme `except Exception` qui masquent les erreurs de programmation en plus des échecs attendus
- Journaliser les exceptions sans les relancer, créant des entrées de log en double et un flux de contrôle confus
- Retourner des codes d’erreur génériques au lieu d’exceptions typées, rendant la gestion des erreurs verbeuse et sujette aux erreurs