Technical Error Handling Diagnostics

You submit a form. You get a 500 Internal Server Error. You file a bug report: "It didn't work."

That bug report tells the developer almost nothing useful. But a tester who understands error responses can write: "HTTP 500 with response body containing 'ArithmeticException: / by zero' at line 47 of CalculationService.java — appears to be an unhandled division by zero in the application layer."

The second report gets fixed in an hour. The first might sit in the backlog for a week.

Reading Error Responses Like a Detective

Error responses have structure. Once you know how to read them, they tell a story:

• HTTP 400: The request was malformed — the client sent something invalid
• HTTP 422: The request was valid but the data didn't pass business rules
• HTTP 500: Something exploded on the server — the application layer failed
• HTTP 503: The service is unavailable — could be DB, could be infrastructure

And within the response body, there are often stack traces, error codes, or domain-specific messages that tell you exactly which component failed.

What You'll Learn

• HTTP status code semantics for mathematical and validation errors
• How to distinguish application-layer errors from database-layer errors
• How to read partial stack traces and error messages in server responses
• Using error patterns to produce high-quality bug reports

Your Practice Challenge

The Crash Log Detective presents a form that crashes at different boundary numbers. Your mission: identify from the error response whether the crash originated in the application code or in the database. The error code in the response is your only clue.