This module provides several classes in support of Joyent\textquotesingle{}s \href{http://www.joyent.com/developers/node/design/errors}{\texttt{ Best Practices for Error Handling in Node.\+js}}. If you find any of the behavior here confusing or surprising, check out that document first.

The error classes here support\+:


\begin{DoxyItemize}
\item printf-\/style arguments for the message
\item chains of causes
\item properties to provide extra information about the error
\item creating your own subclasses that support all of these
\end{DoxyItemize}

The classes here are\+:


\begin{DoxyItemize}
\item {\bfseries{VError}}, for chaining errors while preserving each one\textquotesingle{}s error message. This is useful in servers and command-\/line utilities when you want to propagate an error up a call stack, but allow various levels to add their own context. See examples below.
\item {\bfseries{WError}}, for wrapping errors while hiding the lower-\/level messages from the top-\/level error. This is useful for API endpoints where you don\textquotesingle{}t want to expose internal error messages, but you still want to preserve the error chain for logging and debugging.
\item {\bfseries{SError}}, which is just like VError but interprets printf-\/style arguments more strictly.
\item {\bfseries{Multi\+Error}}, which is just an Error that encapsulates one or more other errors. (This is used for parallel operations that return several errors.)
\end{DoxyItemize}\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31787}{}\doxysection{Quick start}\label{md_sfcode_node_modules_verror_README_autotoc_md31787}
First, install the package\+: \begin{DoxyVerb}npm install verror
\end{DoxyVerb}
 If nothing else, you can use VError as a drop-\/in replacement for the built-\/in Java\+Script Error class, with the addition of printf-\/style messages\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{var err = new VError('missing file: "{}\%s"{}', '/etc/passwd');}
\DoxyCodeLine{console.log(err.message); }

\end{DoxyCode}


This prints\+: \begin{DoxyVerb}missing file: "/etc/passwd"
\end{DoxyVerb}
 You can also pass a {\ttfamily cause} argument, which is any other Error object\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{var fs = require('fs');}
\DoxyCodeLine{var filename = '/nonexistent';}
\DoxyCodeLine{fs.stat(filename, function (err1) \{}
\DoxyCodeLine{    var err2 = new VError(err1, 'stat "{}\%s"{}', filename);}
\DoxyCodeLine{    console.error(err2.message);}
\DoxyCodeLine{\}); }

\end{DoxyCode}


This prints out\+: \begin{DoxyVerb}stat "/nonexistent": ENOENT, stat '/nonexistent'
\end{DoxyVerb}
 which resembles how Unix programs typically report errors\+: \begin{DoxyVerb}$ sort /nonexistent
sort: open failed: /nonexistent: No such file or directory
\end{DoxyVerb}
 To match the Unixy feel, when you print out the error, just prepend the program\textquotesingle{}s name to the VError\textquotesingle{}s {\ttfamily message}. Or just call \href{https://github.com/joyent/node-cmdutil}{\texttt{ node-\/cmdutil.\+fail(your\+\_\+verror)}}, which does this for you.

You can get the next-\/level Error using {\ttfamily err.\+cause()}\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{console.error(err2.cause().message); }

\end{DoxyCode}


prints\+: \begin{DoxyVerb}ENOENT, stat '/nonexistent'
\end{DoxyVerb}
 Of course, you can chain these as many times as you want, and it works with any kind of Error\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{var err1 = new Error('No such file or directory');}
\DoxyCodeLine{var err2 = new VError(err1, 'failed to stat "{}\%s"{}', '/junk');}
\DoxyCodeLine{var err3 = new VError(err2, 'request failed');}
\DoxyCodeLine{console.error(err3.message); }

\end{DoxyCode}


This prints\+: \begin{DoxyVerb}request failed: failed to stat "/junk": No such file or directory
\end{DoxyVerb}
 The idea is that each layer in the stack annotates the error with a description of what it was doing. The end result is a message that explains what happened at each level.

You can also decorate Error objects with additional information so that callers can not only handle each kind of error differently, but also construct their own error messages (e.\+g., to localize them, format them, group them by type, and so on). See the example below.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31788}{}\doxysection{Deeper dive}\label{md_sfcode_node_modules_verror_README_autotoc_md31788}
The two main goals for VError are\+:


\begin{DoxyItemize}
\item {\bfseries{Make it easy to construct clear, complete error messages intended for people.}} Clear error messages greatly improve both user experience and debuggability, so we wanted to make it easy to build them. That\textquotesingle{}s why the constructor takes printf-\/style arguments.
\item {\bfseries{Make it easy to construct objects with programmatically-\/accessible metadata}} (which we call {\itshape informational properties}). Instead of just saying \char`\"{}connection refused while connecting to 192.\+168.\+1.\+2\+:80\char`\"{}, you can add properties like {\ttfamily \char`\"{}ip\char`\"{}\+: \char`\"{}192.\+168.\+1.\+2\char`\"{}} and {\ttfamily \char`\"{}tcp\+Port\char`\"{}\+: 80}. This can be used for feeding into monitoring systems, analyzing large numbers of Errors (as from a log file), or localizing error messages.
\end{DoxyItemize}

To really make this useful, it also needs to be easy to compose Errors\+: higher-\/level code should be able to augment the Errors reported by lower-\/level code to provide a more complete description of what happened. Instead of saying \char`\"{}connection refused\char`\"{}, you can say \char`\"{}operation X failed\+: connection refused\char`\"{}. That\textquotesingle{}s why VError supports {\ttfamily causes}.

In order for all this to work, programmers need to know that it\textquotesingle{}s generally safe to wrap lower-\/level Errors with higher-\/level ones. If you have existing code that handles Errors produced by a library, you should be able to wrap those Errors with a VError to add information without breaking the error handling code. There are two obvious ways that this could break such consumers\+:


\begin{DoxyItemize}
\item The error\textquotesingle{}s name might change. People typically use {\ttfamily name} to determine what kind of Error they\textquotesingle{}ve got. To ensure compatibility, you can create VErrors with custom names, but this approach isn\textquotesingle{}t great because it prevents you from representing complex failures. For this reason, VError provides {\ttfamily find\+Cause\+By\+Name}, which essentially asks\+: does this Error {\itshape or any of its causes} have this specific type? If error handling code uses {\ttfamily find\+Cause\+By\+Name}, then subsystems can construct very specific causal chains for debuggability and still let people handle simple cases easily. There\textquotesingle{}s an example below.
\item The error\textquotesingle{}s properties might change. People often hang additional properties off of Error objects. If we wrap an existing Error in a new Error, those properties would be lost unless we copied them. But there are a variety of both standard and non-\/standard Error properties that should {\itshape not} be copied in this way\+: most obviously {\ttfamily name}, {\ttfamily message}, and {\ttfamily stack}, but also {\ttfamily file\+Name}, {\ttfamily line\+Number}, and a few others. Plus, it\textquotesingle{}s useful for some Error subclasses to have their own private properties -- and there\textquotesingle{}d be no way to know whether these should be copied. For these reasons, VError first-\/classes these information properties. You have to provide them in the constructor, you can only fetch them with the {\ttfamily info()} function, and VError takes care of making sure properties from causes wind up in the {\ttfamily info()} output.
\end{DoxyItemize}

Let\textquotesingle{}s put this all together with an example from the node-\/fast RPC library. node-\/fast implements a simple RPC protocol for Node programs. There\textquotesingle{}s a server and client interface, and clients make RPC requests to servers. Let\textquotesingle{}s say the server fails with an Unauthorized\+Error with message \char`\"{}user \textquotesingle{}bob\textquotesingle{} is not authorized\char`\"{}. The client wraps all server errors with a Fast\+Server\+Error. The client also wraps all request errors with a Fast\+Request\+Error that includes the name of the RPC call being made. The result of this failed RPC might look like this\+: \begin{DoxyVerb}name: FastRequestError
message: "request failed: server error: user 'bob' is not authorized"
rpcMsgid: <unique identifier for this request>
rpcMethod: GetObject
cause:
    name: FastServerError
    message: "server error: user 'bob' is not authorized"
    cause:
        name: UnauthorizedError
        message: "user 'bob' is not authorized"
        rpcUser: "bob"
\end{DoxyVerb}
 When the caller uses {\ttfamily VError.\+info()}, the information properties are collapsed so that it looks like this\+: \begin{DoxyVerb}message: "request failed: server error: user 'bob' is not authorized"
rpcMsgid: <unique identifier for this request>
rpcMethod: GetObject
rpcUser: "bob"
\end{DoxyVerb}
 Taking this apart\+:


\begin{DoxyItemize}
\item The error\textquotesingle{}s message is a complete description of the problem. The caller can report this directly to its caller, which can potentially make its way back to an end user (if appropriate). It can also be logged.
\item The caller can tell that the request failed on the server, rather than as a result of a client problem (e.\+g., failure to serialize the request), a transport problem (e.\+g., failure to connect to the server), or something else (e.\+g., a timeout). They do this using `find\+Cause\+By\+Name(\textquotesingle{}Fast\+Server\+Error'){\ttfamily  rather than checking the}name\`{} field directly.
\item If the caller logs this error, the logs can be analyzed to aggregate errors by cause, by RPC method name, by user, or whatever. Or the error can be correlated with other events for the same rpc\+Msgid.
\item It wasn\textquotesingle{}t very hard for any part of the code to contribute to this Error. Each part of the stack has just a few lines to provide exactly what it knows, with very little boilerplate.
\end{DoxyItemize}

It\textquotesingle{}s not expected that you\textquotesingle{}d use these complex forms all the time. Despite supporting the complex case above, you can still just do\+:

new VError(\char`\"{}my service isn\textquotesingle{}t working\char`\"{});

for the simple cases.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31789}{}\doxysection{Reference\+: VError, WError, SError}\label{md_sfcode_node_modules_verror_README_autotoc_md31789}
VError, WError, and SError are convenient drop-\/in replacements for {\ttfamily Error} that support printf-\/style arguments, first-\/class causes, informational properties, and other useful features.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31790}{}\doxysubsection{Constructors}\label{md_sfcode_node_modules_verror_README_autotoc_md31790}
The VError constructor has several forms\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{/*}
\DoxyCodeLine{ * This is the most general form.  You can specify any supported options}
\DoxyCodeLine{ * (including "{}cause"{} and "{}info"{}) this way.}
\DoxyCodeLine{ */}
\DoxyCodeLine{new VError(options, sprintf\_args...)}
\DoxyCodeLine{}
\DoxyCodeLine{/*}
\DoxyCodeLine{ * This is a useful shorthand when the only option you need is "{}cause"{}.}
\DoxyCodeLine{ */}
\DoxyCodeLine{new VError(cause, sprintf\_args...)}
\DoxyCodeLine{}
\DoxyCodeLine{/*}
\DoxyCodeLine{ * This is a useful shorthand when you don't need any options at all.}
\DoxyCodeLine{ */}
\DoxyCodeLine{new VError(sprintf\_args...) }

\end{DoxyCode}


All of these forms construct a new VError that behaves just like the built-\/in Java\+Script {\ttfamily Error} class, with some additional methods described below.

In the first form, {\ttfamily options} is a plain object with any of the following optional properties\+:

\tabulinesep=1mm
\begin{longtabu}spread 0pt [c]{*{3}{|X[-1]}|}
\hline
\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Option name   }&\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Type   }&\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Meaning    }\\\cline{1-3}
\endfirsthead
\hline
\endfoot
\hline
\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Option name   }&\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Type   }&\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Meaning    }\\\cline{1-3}
\endhead
{\ttfamily name}   &string   &Describes what kind of error this is. This is intended for programmatic use to distinguish between different kinds of errors. Note that in modern versions of Node.\+js, this name is ignored in the {\ttfamily stack} property value, but callers can still use the {\ttfamily name} property to get at it.    \\\cline{1-3}
{\ttfamily cause}   &any Error object   &Indicates that the new error was caused by {\ttfamily cause}. See {\ttfamily cause()} below. If unspecified, the cause will be {\ttfamily null}.    \\\cline{1-3}
{\ttfamily strict}   &boolean   &If true, then {\ttfamily null} and {\ttfamily undefined} values in {\ttfamily sprintf\+\_\+args} are passed through to {\ttfamily sprintf()}. Otherwise, these are replaced with the strings `\textquotesingle{}null'`, and '{\ttfamily undefined}\textquotesingle{}, respectively.    \\\cline{1-3}
{\ttfamily constructor\+Opt}   &function   &If specified, then the stack trace for this error ends at function {\ttfamily constructor\+Opt}. Functions called by {\ttfamily constructor\+Opt} will not show up in the stack. This is useful when this class is subclassed.    \\\cline{1-3}
{\ttfamily info}   &object   &Specifies arbitrary informational properties that are available through the {\ttfamily VError.\+info(err)} static class method. See that method for details.   \\\cline{1-3}
\end{longtabu}


The second form is equivalent to using the first form with the specified {\ttfamily cause} as the error\textquotesingle{}s cause. This form is distinguished from the first form because the first argument is an Error.

The third form is equivalent to using the first form with all default option values. This form is distinguished from the other forms because the first argument is not an object or an Error.

The {\ttfamily WError} constructor is used exactly the same way as the {\ttfamily VError} constructor. The {\ttfamily SError} constructor is also used the same way as the {\ttfamily VError} constructor except that in all cases, the {\ttfamily strict} property is overriden to \`{}true.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31791}{}\doxysubsection{Public properties}\label{md_sfcode_node_modules_verror_README_autotoc_md31791}
{\ttfamily VError}, {\ttfamily WError}, and {\ttfamily SError} all provide the same public properties as Java\+Script\textquotesingle{}s built-\/in Error objects.

\tabulinesep=1mm
\begin{longtabu}spread 0pt [c]{*{3}{|X[-1]}|}
\hline
\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Property name   }&\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Type   }&\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Meaning    }\\\cline{1-3}
\endfirsthead
\hline
\endfoot
\hline
\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Property name   }&\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Type   }&\PBS\centering \cellcolor{\tableheadbgcolor}\textbf{ Meaning    }\\\cline{1-3}
\endhead
{\ttfamily name}   &string   &Programmatically-\/usable name of the error.    \\\cline{1-3}
{\ttfamily message}   &string   &Human-\/readable summary of the failure. Programmatically-\/accessible details are provided through {\ttfamily VError.\+info(err)} class method.    \\\cline{1-3}
{\ttfamily stack}   &string   &Human-\/readable stack trace where the Error was constructed.   \\\cline{1-3}
\end{longtabu}


For all of these classes, the printf-\/style arguments passed to the constructor are processed with {\ttfamily sprintf()} to form a message. For {\ttfamily WError}, this becomes the complete {\ttfamily message} property. For {\ttfamily SError} and {\ttfamily VError}, this message is prepended to the message of the cause, if any (with a suitable separator), and the result becomes the {\ttfamily message} property.

The {\ttfamily stack} property is managed entirely by the underlying Java\+Script implementation. It\textquotesingle{}s generally implemented using a getter function because constructing the human-\/readable stack trace is somewhat expensive.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31792}{}\doxysubsection{Class methods}\label{md_sfcode_node_modules_verror_README_autotoc_md31792}
The following methods are defined on the {\ttfamily VError} class and as exported functions on the {\ttfamily verror} module. They\textquotesingle{}re defined this way rather than using methods on VError instances so that they can be used on Errors not created with {\ttfamily VError}.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31793}{}\doxysubsubsection{$<$tt$>$\+VError.\+cause(err)$<$/tt$>$}\label{md_sfcode_node_modules_verror_README_autotoc_md31793}
The {\ttfamily cause()} function returns the next Error in the cause chain for {\ttfamily err}, or {\ttfamily null} if there is no next error. See the {\ttfamily cause} argument to the constructor. Errors can have arbitrarily long cause chains. You can walk the {\ttfamily cause} chain by invoking {\ttfamily VError.\+cause(err)} on each subsequent return value. If {\ttfamily err} is not a {\ttfamily VError}, the cause is {\ttfamily null}.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31794}{}\doxysubsubsection{$<$tt$>$\+VError.\+info(err)$<$/tt$>$}\label{md_sfcode_node_modules_verror_README_autotoc_md31794}
Returns an object with all of the extra error information that\textquotesingle{}s been associated with this Error and all of its causes. These are the properties passed in using the {\ttfamily info} option to the constructor. Properties not specified in the constructor for this Error are implicitly inherited from this error\textquotesingle{}s cause.

These properties are intended to provide programmatically-\/accessible metadata about the error. For an error that indicates a failure to resolve a DNS name, informational properties might include the DNS name to be resolved, or even the list of resolvers used to resolve it. The values of these properties should generally be plain objects (i.\+e., consisting only of null, undefined, numbers, booleans, strings, and objects and arrays containing only other plain objects).\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31795}{}\doxysubsubsection{$<$tt$>$\+VError.\+full\+Stack(err)$<$/tt$>$}\label{md_sfcode_node_modules_verror_README_autotoc_md31795}
Returns a string containing the full stack trace, with all nested errors recursively reported as `\textquotesingle{}caused by\+:' + err.\+stack\`{}.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31796}{}\doxysubsubsection{$<$tt$>$\+VError.\+find\+Cause\+By\+Name(err, name)$<$/tt$>$}\label{md_sfcode_node_modules_verror_README_autotoc_md31796}
The {\ttfamily find\+Cause\+By\+Name()} function traverses the cause chain for {\ttfamily err}, looking for an error whose {\ttfamily name} property matches the passed in {\ttfamily name} value. If no match is found, {\ttfamily null} is returned.

If all you want is to know {\itshape whether} there\textquotesingle{}s a cause (and you don\textquotesingle{}t care what it is), you can use {\ttfamily VError.\+has\+Cause\+With\+Name(err, name)}.

If a vanilla error or a non-\/\+VError error is passed in, then there is no cause chain to traverse. In this scenario, the function will check the {\ttfamily name} property of only {\ttfamily err}.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31797}{}\doxysubsubsection{$<$tt$>$\+VError.\+has\+Cause\+With\+Name(err, name)$<$/tt$>$}\label{md_sfcode_node_modules_verror_README_autotoc_md31797}
Returns true if and only if {\ttfamily VError.\+find\+Cause\+By\+Name(err, name)} would return a non-\/null value. This essentially determines whether {\ttfamily err} has any cause in its cause chain that has name {\ttfamily name}.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31798}{}\doxysubsubsection{$<$tt$>$\+VError.\+error\+From\+List(errors)$<$/tt$>$}\label{md_sfcode_node_modules_verror_README_autotoc_md31798}
Given an array of Error objects (possibly empty), return a single error representing the whole collection of errors. If the list has\+:


\begin{DoxyItemize}
\item 0 elements, returns {\ttfamily null}
\item 1 element, returns the sole error
\item more than 1 element, returns a Multi\+Error referencing the whole list
\end{DoxyItemize}

This is useful for cases where an operation may produce any number of errors, and you ultimately want to implement the usual {\ttfamily callback(err)} pattern. You can accumulate the errors in an array and then invoke {\ttfamily callback(VError.\+error\+From\+List(errors))} when the operation is complete.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31799}{}\doxysubsubsection{$<$tt$>$\+VError.\+error\+For\+Each(err, func)$<$/tt$>$}\label{md_sfcode_node_modules_verror_README_autotoc_md31799}
Convenience function for iterating an error that may itself be a Multi\+Error.

In all cases, {\ttfamily err} must be an Error. If {\ttfamily err} is a Multi\+Error, then {\ttfamily func} is invoked as {\ttfamily func(error\+N)} for each of the underlying errors of the Multi\+Error. If {\ttfamily err} is any other kind of error, {\ttfamily func} is invoked once as {\ttfamily func(err)}. In all cases, {\ttfamily func} is invoked synchronously.

This is useful for cases where an operation may produce any number of warnings that may be encapsulated with a Multi\+Error -- but may not be.

This function does not iterate an error\textquotesingle{}s cause chain.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31800}{}\doxysubsection{Examples}\label{md_sfcode_node_modules_verror_README_autotoc_md31800}
The \char`\"{}\+Demo\char`\"{} section above covers several basic cases. Here\textquotesingle{}s a more advanced case\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{var err1 = new VError('something bad happened');}
\DoxyCodeLine{/* ... */}
\DoxyCodeLine{var err2 = new VError(\{}
\DoxyCodeLine{    'name': 'ConnectionError',}
\DoxyCodeLine{    'cause': err1,}
\DoxyCodeLine{    'info': \{}
\DoxyCodeLine{        'errno': 'ECONNREFUSED',}
\DoxyCodeLine{        'remote\_ip': '127.0.0.1',}
\DoxyCodeLine{        'port': 215}
\DoxyCodeLine{    \}}
\DoxyCodeLine{\}, 'failed to connect to "{}\%s:\%d"{}', '127.0.0.1', 215);}
\DoxyCodeLine{}
\DoxyCodeLine{console.log(err2.message);}
\DoxyCodeLine{console.log(err2.name);}
\DoxyCodeLine{console.log(VError.info(err2));}
\DoxyCodeLine{console.log(err2.stack); }

\end{DoxyCode}


This outputs\+: \begin{DoxyVerb}failed to connect to "127.0.0.1:215": something bad happened
ConnectionError
{ errno: 'ECONNREFUSED', remote_ip: '127.0.0.1', port: 215 }
ConnectionError: failed to connect to "127.0.0.1:215": something bad happened
    at Object.<anonymous> (/home/dap/node-verror/examples/info.js:5:12)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:935:3
\end{DoxyVerb}
 Information properties are inherited up the cause chain, with values at the top of the chain overriding same-\/named values lower in the chain. To continue that example\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{var err3 = new VError(\{}
\DoxyCodeLine{    'name': 'RequestError',}
\DoxyCodeLine{    'cause': err2,}
\DoxyCodeLine{    'info': \{}
\DoxyCodeLine{        'errno': 'EBADREQUEST'}
\DoxyCodeLine{    \}}
\DoxyCodeLine{\}, 'request failed');}
\DoxyCodeLine{}
\DoxyCodeLine{console.log(err3.message);}
\DoxyCodeLine{console.log(err3.name);}
\DoxyCodeLine{console.log(VError.info(err3));}
\DoxyCodeLine{console.log(err3.stack); }

\end{DoxyCode}


This outputs\+: \begin{DoxyVerb}request failed: failed to connect to "127.0.0.1:215": something bad happened
RequestError
{ errno: 'EBADREQUEST', remote_ip: '127.0.0.1', port: 215 }
RequestError: request failed: failed to connect to "127.0.0.1:215": something bad happened
    at Object.<anonymous> (/home/dap/node-verror/examples/info.js:20:12)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:935:3
\end{DoxyVerb}
 You can also print the complete stack trace of combined {\ttfamily Error}s by using {\ttfamily VError.\+full\+Stack(err).}


\begin{DoxyCode}{0}
\DoxyCodeLine{var err1 = new VError('something bad happened');}
\DoxyCodeLine{/* ... */}
\DoxyCodeLine{var err2 = new VError(err1, 'something really bad happened here');}
\DoxyCodeLine{}
\DoxyCodeLine{console.log(VError.fullStack(err2)); }

\end{DoxyCode}


This outputs\+: \begin{DoxyVerb}VError: something really bad happened here: something bad happened
    at Object.<anonymous> (/home/dap/node-verror/examples/fullStack.js:5:12)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Function.Module.runMain (module.js:441:10)
    at startup (node.js:139:18)
    at node.js:968:3
caused by: VError: something bad happened
    at Object.<anonymous> (/home/dap/node-verror/examples/fullStack.js:3:12)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Function.Module.runMain (module.js:441:10)
    at startup (node.js:139:18)
    at node.js:968:3
\end{DoxyVerb}
 {\ttfamily VError.\+full\+Stack} is also safe to use on regular {\ttfamily Error}s, so feel free to use it whenever you need to extract the stack trace from an {\ttfamily Error}, regardless if it\textquotesingle{}s a {\ttfamily VError} or not.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31801}{}\doxysection{Reference\+: Multi\+Error}\label{md_sfcode_node_modules_verror_README_autotoc_md31801}
Multi\+Error is an Error class that represents a group of Errors. This is used when you logically need to provide a single Error, but you want to preserve information about multiple underying Errors. A common case is when you execute several operations in parallel and some of them fail.

Multi\+Errors are constructed as\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{new MultiError(error\_list) }

\end{DoxyCode}


{\ttfamily error\+\_\+list} is an array of at least one {\ttfamily Error} object.

The cause of the Multi\+Error is the first error provided. None of the other {\ttfamily VError} options are supported. The {\ttfamily message} for a Multi\+Error consists the {\ttfamily message} from the first error, prepended with a message indicating that there were other errors.

For example\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{err = new MultiError([}
\DoxyCodeLine{    new Error('failed to resolve DNS name "{}abc.example.com"{}'),}
\DoxyCodeLine{    new Error('failed to resolve DNS name "{}def.example.com"{}'),}
\DoxyCodeLine{]);}
\DoxyCodeLine{}
\DoxyCodeLine{console.error(err.message); }

\end{DoxyCode}


outputs\+: \begin{DoxyVerb}first of 2 errors: failed to resolve DNS name "abc.example.com"
\end{DoxyVerb}
 See the convenience function {\ttfamily VError.\+error\+From\+List}, which is sometimes simpler to use than this constructor.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31802}{}\doxysubsection{Public methods}\label{md_sfcode_node_modules_verror_README_autotoc_md31802}
\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31803}{}\doxysubsubsection{$<$tt$>$errors()$<$/tt$>$}\label{md_sfcode_node_modules_verror_README_autotoc_md31803}
Returns an array of the errors used to construct this Multi\+Error.\hypertarget{md_sfcode_node_modules_verror_README_autotoc_md31804}{}\doxysection{Contributing}\label{md_sfcode_node_modules_verror_README_autotoc_md31804}
See separate \mbox{\hyperlink{md_sfcode_node_modules_verror_CONTRIBUTING}{contribution guidelines}}. 