Fähigkeiten error-handling-patterns
📦

error-handling-patterns

Sicher

Robuste Fehlerbehandlungsmuster implementieren

Anwendungen scheitern oft unerwartet aufgrund mangelnder Fehlerbehandlung. Diese Skill bietet erprobte Muster für Ausnahmen, Result-Typen, Circuit Breaker und graceful Degradation in Python, TypeScript, Rust und Go.

Unterstützt: Claude Codex Code(CC)
🥉 72 Bronze
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "error-handling-patterns". Add error handling to a function that reads a file and parses JSON content.

Erwartetes Ergebnis:

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

Verwendung von "error-handling-patterns". How should I handle errors in an async function that calls multiple services in parallel?

Erwartetes Ergebnis:

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 });
}
```

Verwendung von "error-handling-patterns". What are the worst error handling anti-patterns to avoid?

Erwartetes Ergebnis:

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.

Sicherheitsaudit

Sicher
v5 • 1/21/2026

All 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.

2
Gescannte Dateien
1,236
Analysierte Zeilen
0
befunde
5
Gesamtzahl Audits
Keine Sicherheitsprobleme gefunden
Auditiert von: claude Audit-Verlauf anzeigen →

Qualitätsbewertung

38
Architektur
100
Wartbarkeit
87
Inhalt
41
Community
100
Sicherheit
87
Spezifikationskonformität

Was du bauen kannst

Produktionsreife API-Fehlerbehandlung aufbauen

Fehlerbehandlung für eine neue REST-API entwerfen, die konsistente Fehlerantworten mit korrekten HTTP-Statuscodes, Fehlercodes und hilfreichen Nachrichten für API-Konsumenten zurückgibt.

Resilienz zu verteilten Systemen hinzufügen

Circuit Breaker und Retry-Muster implementieren, um kaskadierende Ausfälle zu verhindern, wenn externe Dienste nicht verfügbar sind, und sicherstellen, dass das System graceful degradiert.

Code-Review-Feedback zur Fehlerbehandlung verbessern

Spezifisches, umsetzbares Feedback zur Fehlerbehandlung in Pull Requests geben, Anti-Patterns wie leere Catch-Blöcke oder übermäßig breite Ausnahmebehandlung identifizieren.

Probiere diese Prompts

Grundlegende Fehlerbehandlungsimplementierung
Ich brauche Fehlerbehandlung für eine {language}-Funktion, die eine externe API aufruft. Die Funktion sollte bei Netzwerkausfällen mit exponentiellem Backoff erneut versuchen, korrekte Fehlertypen enthalten und klare Fehlermeldungen für das Debugging bereitstellen.
Benutzerdefinierte Ausnahme-Hierarchie entwerfen
Eine benutzerdefinierte Ausnahme-Hierarchie für eine {application_type}-Anwendung entwerfen. Basis-Ausnahme-Klasse, spezifische Fehlertypen für Validierung, nicht gefunden und externe Dienstfehler einschließen. Jede Ausnahme sollte Fehlercode, Zeitstempel und relevanten Kontext enthalten.
Circuit Breaker-Integration
Ein Circuit Breaker-Muster für einen Dienst implementieren, der Aufrufe an eine unzuverlässige Drittanbieter-API tätigt. Konfiguration für Fehlerschwellenwert, Timeout-Dauer und Half-Open-Status für Recovery-Tests einschließen.
Mehrfach-Fehler-Validierungsaggregation
Ein Validierungssystem erstellen, das alle Validierungsfehler sammelt, anstatt beim ersten Fehler zu scheitern. Zeigen, wie Fehler aus mehreren Feldern aggregiert und als strukturierte Antwort zurückgegeben werden.

Bewährte Verfahren

  • Spezifische Ausnahmetypen mit kontextbezogenen Informationen erstellen, einschließlich Fehlercodes, Zeitstempel und relevanten Metadaten für das Debugging
  • Result-Typen oder explizite Fehler-Rückgaben für erwartete Fehler verwenden, um Fehlerbehandlung erzwungen und sichtbar zur Kompilierzeit zu machen, wo möglich
  • Circuit Breaker für externe Abhängigkeiten implementieren, um kaskadierende Ausfälle zu verhindern und graceful Degradation zu ermöglichen
  • Fehler mit angemessener Schwere protokollieren - Error-Level für tatsächliche Probleme, Warning für erwartete Fehler, niemals für normalen Ablauf

Vermeiden

  • Leere Catch-Blöcke, die Fehler stillschweigend verschlucken, Bugs verbergen und Debugging unmöglich machen
  • Übermäßig breite Ausnahme-Handler wie `except Exception`, die Programmierfehler neben erwarteten Fehlern verbergen
  • Ausnahmen protokollieren ohne sie erneut zu werfen, was doppelte Protokolleinträge und verwirrenden Kontrollfluss erzeugt
  • Generische Fehlercodes anstelle von typisierten Ausnahmen zurückgeben, was Fehlerbehandlung umständlich und fehleranfällig macht

Häufig gestellte Fragen

Wann sollte ich Ausnahmen versus Result-Typen verwenden?
Verwenden Sie Ausnahmen für unerwartete, außergewöhnliche Bedingungen wie Netzwerkausfälle, Datei nicht gefunden oder Programmierfehler. Verwenden Sie Result-Typen für erwartete Fehler wie Validierungsfehler, Rate-Limiting oder Geschäftsregelverletzungen. Ausnahmen unterbrechen den Kontrollfluss, während Result-Typen Fehlerbehandlung explizit und erzwungen machen.
Wie entwerfe ich eine gute Fehlerhierarchie?
Beginnen Sie mit einer Basis-ApplicationError, die gemeinsame Felder wie Zeitstempel, Fehlercode und Kontext erfasst. Erstellen Sie spezifische Unterklassen für jede Fehlerdomäne: ValidationError, NotFoundError, ExternalServiceError, AuthenticationError. Vermeiden Sie tiefe Vererbungshierarchien - 2-3 Ebenen sind typischerweise ausreichend.
Was ist ein Circuit Breaker und wann sollte ich einen verwenden?
Ein Circuit Breaker verhindert kaskadierende Ausfälle, indem er Anfragen an einen fehlgeschlagenen Dienst stoppt. Er hat drei Zustände: geschlossen (Normalbetrieb), geöffnet (Anfragen scheitern schnell) und halb-geöffnet (Recovery testen). Verwenden Sie ihn für jeden externen Dienstaufruf, bei dem wiederholte Ausfälle Ressourcen erschöpfen oder die Benutzererfahrung beeinträchtigen könnten.
Wie sollte ich Fehler in asynchronem Code behandeln?
Verwenden Sie in async/await-Code try/catch um await-Anweisungen. Für Promise-Ketten fügen Sie immer .catch()-Handler hinzu. Seien Sie vorsichtig mit unbehandelten Promise-Rejections - sie können Node.js-Prozesse zum Absturz bringen. Erwägen Sie Result-Typen für async-Operationen, um Fehler explizit zu machen.
Welche Informationen sollte ich in Fehlermeldungen einschließen?
Beziehen Sie ein, welcher Vorgang versucht wurde, was die Eingabe oder Ressource war, warum es fehlgeschlagen ist und was der Benutzer oder Entwickler dagegen tun kann. Vermeiden Sie das Offenlegen sensibler Daten. Verwenden Sie strukturierte Formate mit Fehlercodes für programmatische Behandlung.
Wie teste ich Fehlerbehandlung effektiv?
Testen Sie jeden Fehlerpfad explizit mit Mocking, um spezifische Ausfälle zu triggern. Verifizieren Sie, dass Fehler erwarteten Kontext und Codes enthalten. Testen Sie Retry-Logik durch Simulation vorübergehender Ausfälle. Stellen Sie sicher, dass Circuit Breaker unter Ausfallbedingungen korrekt zwischen Zuständen wechseln.