A stack trace is a snapshot of the current method call stack at a point in execution. It records the sequence of calls that led there, commonly including class and method names, file names, and line numbers. Although often produced when an exception is thrown, it can also be generated deliberately for logging, profiling, or debugging. section 7.1.1
Treat a stack trace as developer-facing diagnostic evidence, not as a user-facing error message. A raw trace can overwhelm users and may reveal filesystem paths, internal hostnames, SQL queries, or other sensitive implementation details. Failure handling should translate the failure into an understandable response while retaining useful diagnostic information for investigation. section 7.1.1
Use a stack trace according to the failure context:
- Follow its call sequence to locate the code path and exact line implicated by a reproducible failure. section 10.3.2
- Combine it with timestamps, logs, network traces, metrics, and other evidence when reconstructing an intermittent or unreproducible failure. section 10.3.2
- Escalate beyond it when a fatal runtime failure leaves too little information or the process cannot support normal debugging. section 7.1.4
Tracing an HTTP 500
Reproduce a broken web form, inspect the browser console and network trace, then correlate the HTTP 500 timestamp with backend logs. A stack trace in those logs can pinpoint the faulty line of code, narrowing the investigation from a user-visible symptom to a concrete defect. section 10.3.2
For severe failures, a stack trace may be only one clue. JVM diagnostics can add heap dumps, garbage-collection logs, fatal crash reports, and live runtime data; C and C++ use core dumps and GDB; Rust can emit enabled panic backtraces; Go prints a trace for an unrecovered panic and can create stack dumps. Fatal failures generally call for code or infrastructure correction, or fail-fast behavior, rather than in-process recovery. section 7.1.4
Table 7.1 Summary of failure types and handling strategies
|
Type of failure
|
Description
|
|---|---|
|
Business logic errors
|
Violations of business rules or expected usage constraints that the system must anticipate and communicate clearly
|
|
Technical problems
|
Failures caused by external systems, infrastructure, configuration, or unavailable technical dependencies
|
|
Programming errors
|
Defects in the code itself caused by incorrect logic, invalid assumptions, or broken invariants
|
|
Fatal errors
|
Critical runtime failures that compromise process stability and usually prevent normal recovery
|
Compare fatal errors with business logic errors, technical problems, and programming errors before choosing a response; a trace helps investigate, but does not determine the failure category. section 7.1.4
