OptionalcauseReadonlycodeThe exit code the runtime reported, or null when it reported none.
OptionalstackReadonlytaskThe task-module specifier the abandoned task belonged to.
StaticstackThe Error.stackTraceLimit property specifies the number of stack frames
collected by a stack trace (whether generated by new Error().stack or
Error.captureStackTrace(obj)).
The default value is 10 but may be set to any valid JavaScript number. Changes
will affect any stack trace captured after the value has been changed.
If set to a non-number value, or set to a negative number, stack traces will not capture any frames.
StaticcaptureCreates a .stack property on targetObject, which when accessed returns
a string representing the location in the code at which
Error.captureStackTrace() was called.
const myObject = {};
Error.captureStackTrace(myObject);
myObject.stack; // Similar to `new Error().stack`
The first line of the trace will be prefixed with
${myObject.name}: ${myObject.message}.
The optional constructorOpt argument accepts a function. If given, all frames
above constructorOpt, including constructorOpt, will be omitted from the
generated stack trace.
The constructorOpt argument is useful for hiding implementation
details of error generation from the user. For instance:
function a() {
b();
}
function b() {
c();
}
function c() {
// Create an error without stack trace to avoid calculating the stack trace twice.
const { stackTraceLimit } = Error;
Error.stackTraceLimit = 0;
const error = new Error();
Error.stackTraceLimit = stackTraceLimit;
// Capture the stack trace above function b
Error.captureStackTrace(error, b); // Neither function c, nor b is included in the stack trace
throw error;
}
a();
OptionalconstructorOpt: FunctionStaticprepare
Thrown into a task's promise when its worker's THREAD ENDED while the task was in flight — a clean self-termination (
process.exit()inside the worker, orself.close()on runtimes that report it) as much as an abrupt one.Distinct from
WorkerTaskError, which carries an error the worker managed to report: a thread that simply stops raises nothing, so before the pool observed exits the only thing that ever settled such a task was the task timeout — andtaskTimeoutMs: 0disabled it, leaving the caller's promise pending and the pool slot claimed forever (X8-7).Only raised on runtimes whose worker host reports an exit; where it does not (see
IWorkerHost.reportsExit), the timeout remains the only backstop.Since
0.3.0