Server Exceptions & HTTP 500 (The Mask Off)

When a server-side bug is triggered by a date input, the user rarely sees the actual error. What they see is an HTTP 500 response — the web's way of saying "something went wrong on our end." This module pulls back the curtain on what actually happens between the moment an exception is thrown and the moment the browser receives a 500 status code.

You will learn how web frameworks like Spring, Django, and Express catch unhandled exceptions and translate them into HTTP responses, what kinds of bugs most commonly produce 500 errors (null pointer exceptions, arithmetic errors, stack overflows, memory exhaustion), and how the response body differs between development mode (verbose stack trace) and production mode (sanitized generic message). Understanding this pipeline is essential for both reproducing 500 errors reliably and for assessing the security risk of raw error exposure.

The module also covers the distinction between client errors (4xx) and server errors (5xx) from a tester's perspective. A 400 Bad Request means your input was invalid but the server handled it gracefully. A 500 means the server was surprised by your input and failed. Both are bugs — but 500s are typically higher severity.