jsrosetta

Error handling

Stack Traces

How Node.js's console.trace() compares to debug.Stack() (Go), Backtrace (Rust), callStackSymbols (Swift), and printStackTrace() (Java).

Minimum versions
Node.js ≥ 12.20Go ≥ 1.0Rust ≥ 1.65Swift ≥ 5.1Java ≥ 25
Verified on
Node.js 24.12.0Go 1.27.1Rust 1.98.1Swift 6.2.4Java 25.0.4.1

Node.js code is an ES module: save it as .mjs or set "type": "module" in package.json.

Once an error is caught, you sometimes need to print the whole call path that led to it, not just the message. Node.js has console.trace() right on the global object; Go needs runtime/debug.Stack() called in a deferred function. Rust has std::backtrace::Backtrace, which captures a full trace if called from inside a panic hook — before unwinding begins. Swift doesn't store a stack trace for an Error at all (it's just an ordinary value); the closest thing is capturing Thread.callStackSymbols yourself right where you throw and attaching it to the error. Java is entirely different: every Throwable automatically captures its stack trace when it's constructed — no separate API needed, e.printStackTrace() is enough.

Printing a stack trace when catching an error (console.trace vs debug.Stack)

function foo() {
  throw new Error("failed");
}
 
try {
  foo();
} catch (err) {
  console.trace(err);
}
// → Trace: Error: failed
// →     at foo (file:///…/stack-trace.js:2:9)
// →     at file:///…/stack-trace.js:6:3
// →     … (file paths and line numbers vary by machine and Node.js version)

Reference: github.com/miguelmota/golang-for-nodejs-developers#stack-trace