Error handling for Go HTTP servers — structured error responses, error wrapping,
88
81%
Does it follow best practices?
Impact
99%
1.80xAverage score across 5 eval scenarios
Passed
No known issues
{
"context": "Tests whether the agent proactively adds production error handling when building a Go task tracker API. The task does not mention error handling -- criteria check for custom error types, recovery middleware, structured responses, graceful shutdown, and proper status codes for various failure modes.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Custom error type",
"description": "A custom error struct with StatusCode, Code, and Message fields is defined, implementing the error interface",
"max_score": 12
},
{
"name": "Structured JSON error responses",
"description": "All error responses are JSON with a consistent shape (e.g. {\"error\": {\"code\": \"...\", \"message\": \"...\"}}). No bare http.Error calls, no plain text errors, no mixed formats across handlers.",
"max_score": 12
},
{
"name": "writeError helper",
"description": "A centralized writeError function is used by all handlers to write error responses. Handlers do not format error JSON inline.",
"max_score": 10
},
{
"name": "Recovery middleware",
"description": "A panic recovery middleware using defer/recover is registered that catches panics and returns a structured 500 JSON response",
"max_score": 12
},
{
"name": "Graceful shutdown",
"description": "Server handles SIGTERM/SIGINT with signal.Notify and calls srv.Shutdown with a context timeout",
"max_score": 8
},
{
"name": "No internal error leaks",
"description": "Internal errors return a generic client-facing message -- no raw error strings, file paths, or stack traces leaked in responses",
"max_score": 10
},
{
"name": "Validation status enum",
"description": "The API validates that status values are one of the allowed enum values (todo, in_progress, done) and returns a 400 with a clear message if not",
"max_score": 8
},
{
"name": "Not-found handling",
"description": "Requests for non-existent task IDs return 404 with a structured JSON error, not 500 or 200 with an error message",
"max_score": 8
},
{
"name": "Appropriate status codes",
"description": "Different error conditions return different HTTP status codes: 400 for invalid status/missing title, 404 for not found, 500 for unexpected errors",
"max_score": 10
},
{
"name": "Error wrapping with %w",
"description": "When errors are wrapped with fmt.Errorf, the %w verb is used to preserve the error chain for errors.Is/errors.As",
"max_score": 5
},
{
"name": "All endpoints functional",
"description": "All six endpoints are implemented and return appropriate success status codes",
"max_score": 5
}
]
}