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 parking reservation API with complex business rules (spot availability, time validation, uniqueness constraints). The task does not mention error handling.",
"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 use a consistent JSON shape with code and message fields. No bare http.Error calls, no plain text, no inconsistent formats.",
"max_score": 12
},
{
"name": "writeError helper",
"description": "A centralized writeError function is used by all handlers for error response formatting",
"max_score": 8
},
{
"name": "Recovery middleware",
"description": "A panic recovery middleware using defer/recover is registered that returns structured 500 JSON instead of crashing the server",
"max_score": 12
},
{
"name": "Graceful shutdown",
"description": "Server handles SIGTERM/SIGINT with signal.Notify and srv.Shutdown with a context timeout",
"max_score": 7
},
{
"name": "Business rule errors with proper codes",
"description": "Business rule violations (spot unavailable, time in past, end before start) return appropriate 4xx status codes (400, 409, or 422) with clear messages, not 500",
"max_score": 10
},
{
"name": "Uniqueness conflict as 409",
"description": "Creating a spot with a duplicate level+number combination returns 409 Conflict with a structured error, not 500 or 400",
"max_score": 8
},
{
"name": "Not-found handling",
"description": "Requests for non-existent spots or reservations return 404, not 500 or 200",
"max_score": 8
},
{
"name": "No internal error leaks",
"description": "Internal errors return a generic client-safe message -- no raw error strings or internal details in responses",
"max_score": 8
},
{
"name": "Validation with details",
"description": "Validation errors include details about which fields or conditions failed (e.g. 'endTime must be after startTime', 'licensePlate is required')",
"max_score": 8
},
{
"name": "All endpoints functional",
"description": "All six endpoints are implemented with appropriate success status codes",
"max_score": 5
}
]
}