Editing Stack trace (section)

== Language support ==
Many programming languages, including [[Java (programming language)|Java]]<ref>{{cite web | title=Thread (Java SE 16 & JDK 16) | website=Java Platform Standard Edition & Java Development Kit Version 16 API Specification | date=2021-03-04 | url=https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/Thread.html#getStackTrace() | access-date=2021-07-04}}</ref> and [[C Sharp (programming language)|C#]],<ref>{{cite web | title=Environment.StackTrace Property (System) | website=Microsoft Docs | date=2021-05-07 | url=https://docs.microsoft.com/en-us/dotnet/api/system.environment.stacktrace | access-date=2021-07-04}}</ref> have built-in support for retrieving the current stack trace via system calls. Before <code>std::stacktrace</code> was added in standard library as a container for <code>std::stacktrace_entry</code>, pre-[[C++23]] has no built-in support for doing this, but C++ users can retrieve stack traces with (for example) the [http://stacktrace.sourceforge.net/ stacktrace] [[library (computing)|library]]. In [[JavaScript]], [[Exception handling|exceptions]] hold a <code>stack</code> property that contain the stack from the place where it was thrown.

=== Python ===
As an example, the following [[Python (programming language)|Python]] program contains an error.
<syntaxhighlight lang="python" line="1" highlight="3,9,13,15">
def a():
    i = 0
    j = b(i)
    return j

def b(z):
    k = 5
    if z == 0:
        c()
    return k + z

def c():
    error()

a()
</syntaxhighlight>
Running the program under the standard Python interpreter produces the following error message.
<syntaxhighlight lang="pytb">
Traceback (most recent call last):
  File "file.py", line 15, in <module>
    a()
  File "file.py", line 3, in a
    j = b(i)
  File "file.py", line 9, in b
    c()
  File "file.py", line 13, in c
    error()
NameError: name 'error' is not defined
</syntaxhighlight>
The stack trace shows where the error occurs, namely in the <code>c</code> function. It also shows that the <code>c</code> function was called by <code>b</code>, which was called by <code>a</code>, which was in turn called by the code on line 15 (the last line) of the program. The activation records for each of these three functions would be arranged in a stack such that the <code>a</code> function would occupy the bottom of the stack and the <code>c</code> function would occupy the top of the stack.

=== Java ===
In [[Java (programming language)|Java]], stack traces can be dumped manually with <code>Thread.dumpStack()</code><ref>{{Cite web|title=Thread (Java Platform SE 8 )|url=https://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#dumpStack--|access-date=2021-06-15|website=docs.oracle.com}}</ref> Take the following input:
<syntaxhighlight lang="java" line="1" highlight="3,6,12,15">
public class Main {
  public static void main(String args[]) {
    demo();
  }
  static void demo() {
    demo1();
  }
  static void demo1() {
    demo2();
  }
  static void demo2() {
    demo3();
  }
  static void demo3() {
    Thread.dumpStack();
  }
}
</syntaxhighlight>

The exception lists functions in descending order, so the most-inner call is first.

<syntaxhighlight lang="java">
java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:1336)
        at Main.demo3(Main.java:15)
        at Main.demo2(Main.java:12)
        at Main.demo1(Main.java:9)
        at Main.demo(Main.java:6)
        at Main.main(Main.java:3)
</syntaxhighlight>

=== C and C++ ===
Both [[C (programming language)|C]] and [[C++]] (pre-[[C++23]]) do not have native support for obtaining stack traces, but libraries such as [[GNU C Library|glibc]] and [[Boost (C++ libraries)|boost]] provide this functionality.<ref name="glibc Backtraces">{{Cite web|title=Backtraces (The GNU C Library)|url=https://www.gnu.org/software/libc/manual/html_node/Backtraces.html|access-date=2021-06-15|website=www.gnu.org}}</ref><ref>{{Cite web|title=Getting Started - 1.76.0|url=https://www.boost.org/doc/libs/1_76_0/doc/html/stacktrace/getting_started.html|access-date=2021-06-15|website=www.boost.org}}</ref> In these languages, some compiler optimizations may interfere with the call stack information that can be recovered at runtime. For instance, [[Inline expansion|inlining]] can cause missing stack frames, [[tail call]] optimizations can replace one stack frame with another, and frame pointer elimination can prevent call stack analysis tools from correctly interpreting the contents of the call stack.<ref name="glibc Backtraces" />

For example, glibc's <code>backtrace()</code> function returns an output with the program function and memory address.
<syntaxhighlight lang="c">
./a.out() [0x40067f]
./a.out() [0x4006fe]
./a.out() [0x40070a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f7e60738f45]
./a.out() [0x400599]
</syntaxhighlight>

As of [[C++23]], stack traces can be dumped manually by printing the value returned by static member function <code>std::stacktrace::current()</code>:<ref>{{Cite web|date=2021-10-23|title=Working Draft, Standard for Programming Language C++|url=http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/n4901.pdf|website=open-std.org|publisher=ISO/IEC|page=766}}</ref>
<syntaxhighlight lang="c++">
std::cout << std::stacktrace::current() << '\n';
</syntaxhighlight>

=== Rust ===
[[Rust (programming language)|Rust]] has two types of errors. Functions that use the panic [[Macro (computer science)|macro]] are "unrecoverable" and the current thread will become poisoned experiencing stack unwinding. Functions that return a <code>std::result::Result</code> are "recoverable" and can be handled gracefully.<ref>{{Cite web|title=rustonomicon unwinding - Rust|url=https://doc.rust-lang.org/nomicon/unwinding.html#:~:text=Rust%20has%20a%20tiered%20error,be%20handled%2C%20the%20thread%20panics.|website=doc.rust-lang.org}}</ref> However, recoverable errors cannot generate a stack trace as they are manually added and not a result of a runtime error.

As of June 2021, [[Rust (programming language)|Rust]] has experimental support for stack traces on unrecoverable errors. Rust supports printing to [[stderr]] when a thread panics, but it must be enabled by setting the <code>RUST_BACKTRACE</code> [[environment variable]].<ref>{{Cite web|title=std::backtrace - Rust|url=https://doc.rust-lang.org/std/backtrace/index.html|access-date=2021-06-15|website=doc.rust-lang.org}}</ref>

When enabled, such backtraces look similar to below, with the most recent call first.
<syntaxhighlight lang="rust">
thread 'main' panicked at 'execute_to_panic', main.rs:3
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: futures::task_impl::with
   6: futures::task_impl::park
...
</syntaxhighlight>