Use consistent error types

Always use the appropriate error classes and throwing mechanisms for consistent error handling across the codebase. Prefer `BetterAuthError` or `APIError` over generic `Error` classes, use `throw` instead of returning error responses in endpoints, and structure error codes consistently.

copy reviewer prompt

Prompt

Reviewer Prompt
Deploy Agent

Always use the appropriate error classes and throwing mechanisms for consistent error handling across the codebase. Prefer BetterAuthError or APIError over generic Error classes, use throw instead of returning error responses in endpoints, and structure error codes consistently.

Key practices:

  • Use BetterAuthError instead of new Error() for domain-specific errors
  • Use throw ctx.error or throw new APIError in endpoints instead of return ctx.json(error)
  • Use toThrowError with specific error details in tests instead of generic toThrow()
  • Structure error codes consistently using ERROR_CODES constants
  • Use appropriate HTTP status codes (e.g., BAD_REQUEST instead of USER_NOT_FOUND for client errors)

Example:

// ❌ Avoid
throw new Error("unable to set a future iat time");
return ctx.json({ error: "invalid_grant" }, { status: 400 });

// ✅ Prefer  
throw new BetterAuthError("unable to set a future iat time");
throw new APIError("BAD_REQUEST", {
  message: ERROR_CODES.INVALID_GRANT,
  code: "INVALID_GRANT"
});

This ensures proper error type inference, consistent error handling patterns, and better debugging experience across the application.

Source discussions