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-3/

{
  "context": "Tests whether the agent proactively applies FastAPI error handling best practices when building an order management API. The task describes a state machine and business rules that naturally produce errors, but says nothing about exception handlers, error response formatting, or validation customization -- the agent should add these on its own.",
  "type": "weighted_checklist",
  "checklist": [
    {
      "name": "Custom exception classes defined",
      "description": "Agent defines custom exception classes (e.g. NotFoundError, BusinessRuleError, InvalidStateTransition) rather than using bare HTTPException with string details throughout. The agent was NOT asked to create custom exceptions.",
      "max_score": 12
    },
    {
      "name": "Exception handler for custom errors registered",
      "description": "Agent registers @app.exception_handler for custom exception types that returns structured JSON with a machine-readable 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 produce structured validation errors with field-level detail, replacing FastAPI's default 422 format. 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. The agent was NOT asked about catch-all error handling.",
      "max_score": 14
    },
    {
      "name": "Consistent error response structure",
      "description": "All error responses use the same JSON shape with a code/type and message, whether the error is a validation failure, not-found, invalid state transition, or unexpected server error.",
      "max_score": 12
    },
    {
      "name": "No internal details leaked in errors",
      "description": "Error responses for unexpected failures contain no Python tracebacks, file paths, or raw exception messages -- only a safe generic message.",
      "max_score": 8
    },
    {
      "name": "Semantically correct HTTP status codes",
      "description": "Agent uses appropriate status codes: 404 for order not found, 409 or 422 for invalid state transitions, 400/422 for validation errors (empty items, invalid quantity), 500 for unexpected errors.",
      "max_score": 10
    },
    {
      "name": "Server-side error logging",
      "description": "The catch-all handler logs the real error using logging, structlog, or similar before returning the generic response. The agent was NOT asked to add logging.",
      "max_score": 8
    },
    {
      "name": "Validation errors include field-level detail",
      "description": "The RequestValidationError handler returns per-field error information (field name and what went wrong) rather than a single opaque error string.",
      "max_score": 8
    }
  ]
}

evals

tile.json