From 01f96ee6197a7b5a2c64353a3b38260994ce5ad5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Gustavsson?= Date: Thu, 16 Nov 2017 06:10:12 +0100 Subject: Add documentation for the new stacktrace syntax --- system/doc/reference_manual/errors.xml | 47 +++++++++++++++++++++++++++++++--- 1 file changed, 44 insertions(+), 3 deletions(-) (limited to 'system/doc/reference_manual/errors.xml') diff --git a/system/doc/reference_manual/errors.xml b/system/doc/reference_manual/errors.xml index b16c5da6eb..16d3e7590e 100644 --- a/system/doc/reference_manual/errors.xml +++ b/system/doc/reference_manual/errors.xml @@ -108,14 +108,55 @@ (see Exit Reason), and a stack trace (which aids in finding the code location of the exception).

-

The stack trace can be retrieved using - erlang:get_stacktrace/0 - from within a try expression, and is returned for +

The stack trace can be be bound to a variable from within + a try expression, and is returned for exceptions of class error from a catch expression.

An exception of class error is also known as a run-time error.

+ +
+ The call-stack back trace (stacktrace) +

The stack back-trace (stacktrace) is a list of + {Module,Function,Arity,Location} + tuples. The field Arity in the first tuple can be the + argument list of that function call instead of an arity integer, + depending on the exception.

+ +

Location is a (possibly empty) list of two-tuples + that can indicate the location in the source code of the + function. The first element is an atom describing the type of + information in the second element. The following items can + occur:

+ + file + The second element of the tuple is a string (list of + characters) representing the filename of the source file + of the function. + + line + The second element of the tuple is the line number + (an integer > 0) in the source file + where the exception occurred or the function was called. + + +

Developers should rely on stacktrace entries only for + debugging purposes.

+

The VM performs tail call optimization, which + does not add new entries to the stacktrace, and also limits stacktraces + to a certain depth. Furthermore, compiler options, optimizations and + future changes may add or remove stacktrace entries, causing any code + that expects the stacktrace to be in a certain order or contain specific + items to fail.

+

The only exception to this rule is the class error with the + reason undef which is guaranteed to include the Module, + Function and Arity of the attempted + function as the first stacktrace entry.

+
+
+ +
Handling of Run-time Errors in Erlang -- cgit v1.2.3