CtrlK
BlogDocsLog inGet started
Tessl Logo

tessl-labs/fastapi-error-handling

Production error handling for FastAPI — exception handlers, structured error

96

6.12x
Quality

96%

Does it follow best practices?

Impact

98%

6.12x

Average score across 5 eval scenarios

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

criteria.jsonevals/scenario-5/

{
  "context": "Tests whether the agent proactively applies FastAPI error handling best practices when building a user registration API. The task does not mention exception handlers, error formatting, or structured responses -- the agent should add these on its own.",
  "type": "weighted_checklist",
  "checklist": [
    {
      "name": "Custom exception classes defined",
      "description": "Agent defines custom exception classes (not just bare HTTPException) for domain errors like not-found, conflict, and validation errors. The agent was NOT asked to create exception classes.",
      "max_score": 12
    },
    {
      "name": "Exception handler for custom errors registered",
      "description": "Agent registers @app.exception_handler for custom exception types, returning structured JSON with a code and message. The agent was NOT asked to register exception handlers.",
      "max_score": 14
    },
    {
      "name": "RequestValidationError handler registered",
      "description": "Agent registers @app.exception_handler(RequestValidationError) to customize the default 422 Pydantic validation response into a structured format with per-field errors. The agent was NOT asked to customize validation errors.",
      "max_score": 14
    },
    {
      "name": "Generic Exception catch-all handler",
      "description": "Agent registers @app.exception_handler(Exception) that catches unexpected errors and returns a safe generic message without leaking internals. The agent was NOT asked about catch-all error handling.",
      "max_score": 14
    },
    {
      "name": "Consistent error response shape",
      "description": "All error responses across all endpoints use the same JSON structure (e.g. {\"error\": {\"code\": ..., \"message\": ...}}) with a machine-readable code and a human-readable message.",
      "max_score": 12
    },
    {
      "name": "Password never in error details",
      "description": "Error responses for password-related failures (wrong old password, weak new password) do not echo back the password values in the response body.",
      "max_score": 8
    },
    {
      "name": "Appropriate HTTP status codes for domain errors",
      "description": "Agent uses 404 for user not found, 409 for duplicate username/email, 400 or 422 for invalid input, 403 or 400 for wrong old password. Not all errors mapped to the same status code.",
      "max_score": 10
    },
    {
      "name": "Server-side error logging",
      "description": "The catch-all exception handler logs the actual error (using logging, structlog, or similar) before returning the safe response. The agent was NOT asked to add logging.",
      "max_score": 8
    },
    {
      "name": "Validation error details include field names",
      "description": "The RequestValidationError handler returns per-field error details (field name and message) rather than a single opaque error string.",
      "max_score": 8
    }
  ]
}

evals

tile.json