error-handling-patterns
Implementar padrões robustos de tratamento de erros
Aplicações frequentemente falham inesperadamente devido ao tratamento inadequado de erros. Esta skill fornece padrões testados em produção para exceções, tipos Result, circuit breakers e degradação gradual em Python, TypeScript, Rust e Go.
Baixar o ZIP da skill
Upload no Claude
Vá em Configurações → Capacidades → Skills → Upload skill
Ative e comece a usar
Testar
A utilizar "error-handling-patterns". Adicione tratamento de erros a uma função que lê um arquivo e faz parse de conteúdo JSON.
Resultado esperado:
Aqui está um padrão para tratamento robusto de arquivos com hierarquia de erros apropriada:
**Exemplo Python:**
```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
```
**Práticas principais:**
- Use tipos de exceção específicos para diferentes cenários de erro
- Inclua informações contextuais nas exceções
- Encadeie exceções para preservar a stack trace original
- Use context managers para limpeza automática de recursos
A utilizar "error-handling-patterns". Como devo tratar erros em uma função async que chama múltiplos serviços em paralelo?
Resultado esperado:
Para chamadas de serviços em paralelo, considere estas estratégias:
**Opção 1: Agregar Erros**
Colete todos os erros e reporte-os juntos em vez de falhar no primeiro erro.
```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 };
}
```
**Opção 2: Tipos Result**
Use tipos explícitos de sucesso/falha para cada operação.
```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 });
}
```
A utilizar "error-handling-patterns". Quais são os piores anti-padrões de tratamento de erros a evitar?
Resultado esperado:
Aqui estão os anti-padrões mais perigosos e suas correções:
**Anti-Padrão 1: Blocos Catch Vazios**
```python
try:
do_something()
except:
pass # Silent failure - bugs hide forever
```
**Correção:** Sempre registre em log ou relance exceções.
**Anti-Padrão 2: Capturar de Forma Muito Ampla**
```python
try:
do_something()
except Exception:
# Hides bugs including typos and logic errors
pass
```
**Correção:** Capture apenas tipos de exceção específicos.
**Anti-Padrão 3: Engolir Após Registrar em Log**
```python
try:
do_something()
except Exception as e:
logger.error(e)
# Error logged but not handled - caller doesn't know it failed
```
**Correção:** Relance ou retorne resultado de erro.
**Anti-Padrão 4: Erros Excessivamente Genéricos**
```python
raise Exception("Error occurred") # No context, no code, useless for debugging
```
**Correção:** Inclua o que aconteceu, o que estava sendo processado e códigos de erro.
Auditoria de Segurança
SeguroAll 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.
Pontuação de qualidade
O Que Você Pode Construir
Construir tratamento de erros de API de nível de produção
Projetar tratamento de erros para uma nova REST API que retorna respostas de erro consistentes com códigos de status HTTP apropriados, códigos de erro e mensagens úteis para consumidores da API.
Adicionar resiliência a sistemas distribuídos
Implementar padrões de circuit breaker e retry para prevenir falhas em cascata quando serviços externos ficam indisponíveis, garantindo que o sistema degrade de forma gradual.
Melhorar feedback de code review sobre tratamento de erros
Fornecer feedback específico e acionável sobre tratamento de erros em pull requests, identificando anti-padrões como blocos catch vazios ou tratamento de exceções excessivamente amplo.
Tente Estes Prompts
Preciso de tratamento de erros para uma função em {language} que chama uma API externa. A função deve fazer retry em falhas de rede com exponential backoff, incluir tipos de erro apropriados e fornecer mensagens de erro claras para debugging.Projete uma hierarquia de exceções customizada para uma aplicação {application_type}. Inclua classe de exceção base, tipos de erro específicos para validação, not found e falhas de serviços externos. Cada exceção deve incluir código de erro, timestamp e contexto relevante.Implemente um padrão circuit breaker para um serviço que faz chamadas a uma API de terceiros não confiável. Inclua configuração para limite de falhas, duração de timeout e estado half-open para testes de recuperação.
Crie um sistema de validação que coleta todos os erros de validação em vez de falhar no primeiro. Mostre como agregar erros de múltiplos campos e retorná-los como uma resposta estruturada.
Melhores Práticas
- Criar tipos de exceção específicos com informações contextuais incluindo códigos de erro, timestamps e metadados relevantes para debugging
- Usar tipos Result ou retornos de erro explícitos para falhas esperadas para tornar o tratamento de erros forçado e visível em tempo de compilação quando possível
- Implementar circuit breakers para dependências externas para prevenir falhas em cascata e permitir degradação gradual
- Registrar erros em log com severidade apropriada - nível error para problemas reais, warning para falhas esperadas, nunca para fluxo normal
Evitar
- Blocos catch vazios que engolem erros silenciosamente, escondendo bugs e tornando o debugging impossível
- Tratadores de exceção excessivamente amplos como `except Exception` que mascaram erros de programação junto com falhas esperadas
- Registrar exceções em log sem relançá-las, criando entradas de log duplicadas e fluxo de controle confuso
- Retornar códigos de erro genéricos em vez de exceções tipadas, tornando o tratamento de erros verboso e propenso a erros
Perguntas Frequentes
Quando devo usar exceções versus tipos Result?
Como projeto uma boa hierarquia de erros?
O que é um circuit breaker e quando devo usar um?
Como devo tratar erros em código assíncrono?
Quais informações devo incluir nas mensagens de erro?
Como testo tratamento de erros efetivamente?
Detalhes do Desenvolvedor
Autor
wshobsonLicença
MIT
Repositório
https://github.com/wshobson/agents/tree/main/plugins/developer-essentials/skills/error-handling-patternsReferência
main
Estrutura de arquivos
📄 SKILL.md