Error Handling Conventions

error-handlingreliabilitybest-practicesbackend

Conventions for consistent and safe error handling across the codebase

Целевые файлы

Файл	Формат
.cursorrules	plaintext
CLAUDE.md	markdown

Содержимое

Never silently swallow errors; always log or re-throw with additional context. Use typed error classes (AppError, ValidationError, NotFoundError) instead of generic Error. Include an error code string in every error for programmatic handling by clients. Attach context to errors when re-throwing: wrap with cause to preserve the original stack. Distinguish between operational errors (expected, log+respond) and programmer errors (crash). In async code always use try/catch or .catch(); never leave Promise rejections unhandled. Return user-safe error messages to clients; never expose internal errors or stack traces. Use a global error handler (middleware or process.on) as a last resort, not primary handling. Validate inputs at the entry point and throw validation errors before business logic runs. In Go: always check returned errors; never use _ to discard an error value. In Rust: propagate errors with ? and use thiserror for defining typed error enums. Document which errors a public function can throw/return in its JSDoc or rustdoc. Test error paths explicitly: every function that can fail should have failure test cases. Implement retry with exponential backoff for transient errors from external services.

CLI

npx mindaxis apply error-handling-rules --target cursor --scope project