FaunaError and it's sub-types eat the stack trace.

[milyord]

faunadb-js/src/errors.js

Lines 21 to 41 in 18d58e7

	function FaunaError(name, message, description) {
	Error.call(this)
	/**
	* Name of this exception.
	* @type {string}
	*/
	this.name = name
	/**
	* Message for this exception.
	* @type {string}
	*/
	this.message = message
	/**
	* Description for this exception.
	* @type {string}
	*/
	this.description = description
	}

Extending the Error object is not ideal in JavaScript. You're better-off just decorating instances of Error like this:

function FaunaError(error) {
  error.name = "FaunaError";
  error.message = `Some Decoration - ${error.message}`;
  Object.defineProperty(error, "type", {value: "FaunaError"});
  return error;
}

And then when you need to use it:

// instanceof is a liar. Use error.type or invent your own API and stick to it.
throw FaunaError(Error("JavaScript !== Python && JavaScript !== Java && JavaScript !== ..."));

Benefits of this approach:

1. Preserves the stack trace and all other desirable properties of an error.
2. No need to use the new keyword.
3. Simplifies your codebase and gets rid of all sub-typing boilerplate code e.g. _utils/inherits.

There might be downsides to this approach but I doubt any would be worse than loosing the stack trace.

Regardless of whether you like this approach or not FaunaError eats the stack trace and that's a bug.

[fireridlle]

Extends custom errors from the Error class considered as a best practice.
Stack trace issue fixed and will be released soon

[faunaee]

@milyord Just curious, but how would the stack trace from a Fauna Error help you?