bjyoungblood/es6-error

Easily-extendable error for use with ES6 classes

es6-error

An easily-extendable error class for use with ES6 classes (or ES5, if you so choose).

Tested in Node 4.0, Chrome, and Firefox.

Why?

I made this because I wanted to be able to extend Error for inheritance and type checking, but can never remember to add Error.captureStackTrace(this, this.constructor.name) to the constructor or how to get the proper name to print from console.log.

ES6 Usage

import ExtendableError from 'es6-error';

class MyError extends ExtendableError {
  // constructor is optional; you should omit it if you just want a custom error
  // type for inheritance and type checking
  constructor(message = 'Default message') {
    super(message);
  }
}

export default MyError;

ES5 Usage

var util = require('util');
var ExtendableError = require('es6-error');

function MyError(message) {
  message = message || 'Default message';
  ExtendableError.call(this, message);
}

util.inherits(MyError, ExtendableError);

module.exports = MyError;

Known Issues

• Uglification can obscure error class names (#31)

Todo

• Better browser compatibility
• Browser tests

es6-error's Issues

TypeError: Object prototype may only be an Object or null: undefined

Hello,

i'm getting this error. Typescript 2.7.2
TypeError: Object prototype may only be an Object or null: undefined
at setPrototypeOf (native)
[Node] at __extends

Any idea why?

jsnext:main should not point to completely untranspiled code

From the Rollup docs:

jsnext:main will point to a module that has ES2015 module syntax but otherwise only syntax features that node supports.

Libraries that expose an ES6 module build should transpile the code in a way that makes it ES5-compatible, but leaves "import" and "export" statements intact. The reason is that we can't transpile all node_modules for a project, nor would we know what babel config to use on each of them. See this conversation for more discussion. Pointing "jsnext:main" to a file with the "class" keyword is breaking our build.

jsnext:main usage

See #22 (and #23) for background.

I'm not currently using Rollup myself, so I'm not 100% sure how jsnext:main is supposed to work.

For a single-file module, it seems like the ES module syntax won't really provide any benefit (no need for tree-shaking as there is no tree to shake). If we just removed jsnext:main, would Rollup work properly?

Alternatively, it sounds like we could create a second build that does not use the add-module-exports Babel plugin and point jsnext:main to that.

Strategy for `name` property given uglification?

Given that name is determined via this.constructor.name, if one were to minify their code and mangle the names, this could lead to new MyCustomError().name === 'e'.

babel config causes error with React Native

Having the "babel" key in package.json seems to throw an error when required from React Native.

The specific error is:

ReferenceError: Unknown plugin "add-module-exports" specified in "node_modules/es6-error/package.json" at 0, attempted to resolve relative to "node_modules/es6-error"

Fixing this should be as simple as moving the config to a .babelrc file.

Breaking changes for 4.1.0 behavior

Test cases

import ExtendableError from 'es6-error`;

class A extends ExtendableError {
  super('foo');
  this.name = 'bar';
} 

const errorA = new A();
console.log(errorA instanceof A)

On version
4.0.2 https://gist.github.com/tinder-rhsiao/aaa1082eb6575b7ee6f591f958adec61 will return true
4.1.0 https://gist.github.com/tinder-rhsiao/e8c7a1255f3def0ad4a72200a2c91dae returns false

doesn't seems transform-builtin-extend is outputting as is, not sure if it is expected.

Unable to import using TypeScript on nodejs

In Typescript, this line:

import ExtendableError from 'es6-error'

translates to this line:

var ExtendableError = require('es6-error').default

However, .default is undefined due to the incorrect way these two lines are written. A correct version of those two lines would read like this:

module.exports = ExtendableError;
module.exports.default = ExtendableError;

dist was not built on last publish

latest publish does not contain fixes to err.message inside the dist folder.
i have babel disabled for node_modules so this bugs me :)

Edit: babel disabled does not matter since package.json points at dist/index.js

TypeError on 4.1.0 and 4.1.1 (but not 4.0.2)

On versions 4.1.0 and 4.1.1, I'm seeing the error:

Uncaught TypeError: Super expression must either be null or a function, not undefined

Downgrading to 4.0.2 fixes it. I wasn't able to create a minimum reproducible test case, but the actual code I'm running is in https://github.com/frictionlessdata/tableschema-js/blob/ded028d7462e48584971faa9bae407cdc338433b/src/errors.js

pkg.main, pkg.module are incompatible, so require("es6-error") behaves differently under Rollup/Webpack

In Node, require("es6-error") returns the function ExtendableError, but in Rollup or Webpack, require("es6-error") returns a module { default: ExtendableError }. This means an es6-error dependent can’t be compatible with both environments without contortions.

$ echo 'console.log(require("es6-error"))' > src.js
$ npm i quickselect webpack webpack-cli
$ node src.js
[Function: ExtendableError]
$ npx rollup src.js -p node-resolve -p commonjs -f cjs -o out.js
$ node out.js
[Object: null prototype] { default: [Function: ExtendableError] }
$ npx webpack -d
$ node dist/main.js 
Object [Module] { default: [Function: ExtendableError] }

This is because Node is using pkg.main (./lib/index), while Rollup and Webpack are using pkg.module (./es6/index.js), and the two files do not provide compatible interfaces.

Three potential solutions are:

• disable babel-plugin-add-module-exports, so require("es6-error").default would work everywhere; or
• add ExtendableError.default = ExtendableError for compatibility; or
• remove pkg.module.

TypeError: Cannot read property 'prototype' of undefined"," at __extends

Hi

Getting above error when using with Typescript 2.1. This is where the error occurs on ES5 code generated under b.prototype:

var __extends = (this && this.__extends) || function (d, b) { for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p]; function __() { this.constructor = d; } d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __()); };

Here's is how i'm calling the module:

import ExtendableError from "es6-error";

export class AuthenticationError extends ExtendableError {}`

The ES5 version works:

`var util = require('util');
var ExtendableError = require('es6-error');

function AuthenticationError(message) {
message = message || 'Default message';
ExtendableError.call(this, message);
}

util.inherits(AuthenticationError, ExtendableError);

export {AuthenticationError}`

What am i doing wrong?

Curious about choices

I'm comparing your implementation to this one: https://gist.github.com/daliwali/09ca19032ab192524dc6

For instance:

• Error.call(this, message) vs super(message)
• Object.defineProperty(this, 'name' ... vs get name()
• Lack of if (Error.hasOwnProperty('captureStackTrace'))
• Lack of fallback to Object.defineProperty(this, 'stack', {

I see in your commit history that you had some of this and then changed it. I'd love to learn what problems you had or reasons for the changes.

Thanks!

Unable to alter stack trace.

I have a custom error object and I've built in the ability to set and update message along with the stack trace.

https://github.com/reggi/error-suite/blob/master/src/multi-error.js#L27

It seems like you've locked any changes to this.stack from your end so It's read-only for me.

http://stackoverflow.com/questions/36986345/typeerror-stack-is-read-only

Can you update this so I can update the message in my stack trace?

Consider deprecating this package

I don't like to rain on other people's parades, but the examples in the README.md can be rewritten rather more simply as:

ES6 Usage

class MyError extends Error {}
MyError.prototype.name = 'MyError';
Object.defineProperty(MyError.prototype, 'name', {enumerable : false});  // Optional.

ES5 Usage

function MyError(message) {
  return Object.setPrototypeOf(new Error(message), MyError.prototype);
}
Object.setPrototypeOf(MyError.prototype, Error.prototype);
MyError.prototype.name = 'MyError';
Object.defineProperty(MyError.prototype, 'name', {enumerable: false});  // Optional.

These are both (AFAICT) exactly equivalent, and have the following advantages:

• One fewer external dependency.
• Shorter and simpler code.
• The .name goes on the .prototype, instead of every instance. This saves memory and is more consistent with existing Error classes.
• No .message property is created if no message is supplied to the constructor. This is more consistent with existing Error classes—and of course if you do want a default message, then it's easily done via the constructor as in the existing example.
• Does not depend on the node.js-specific Error.captureStackTrace function.

`.message` is not defined

When used with babel, e.message returns nothing.

➜ ~ % node -v
v4.0.0

import ExError from 'es6-error'

export default class UserNotFound extends ExError {
}

try {
  throw new UserNotFound(':)')
} catch (e) {
  console.log(e.message)
  console.log(typeof e.message)
  console.log(e.message.length)
}

➡️

string
0

Does not work in combination with longjohn

When used in combination with https://github.com/mattinsler/longjohn, produces no stack trace.

Extending Error object directly:

/Users/gajus/Documents/dev/gajus/mightyql/dist/index.js:86
    throw new _errors.NotFoundError();
          ^
Error: Resource not found.
    at exports.many (/Users/gajus/Documents/dev/gajus/mightyql/dist/index.js:86:11)
---------------------------------------------
    at Object.<anonymous> (/Users/gajus/Documents/dev/applaudience/showtime-api/src/bin/server.js:42:9)
    at Module._compile (module.js:571:32)
    at loader (/Users/gajus/Documents/dev/applaudience/showtime-api/node_modules/babel-register/lib/node.js:144:5)
    at Object.require.extensions.(anonymous function) [as .js] (/Users/gajus/Documents/dev/applaudience/showtime-api/node_modules/babel-register/lib/node.js:154:7)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Function.Module.runMain (module.js:605:10)
    at Object.<anonymous> (/Users/gajus/Documents/dev/applaudience/showtime-api/node_modules/babel-cli/lib/_babel-node.js:154:22)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.runMain (module.js:605:10)

Extending es6-error:

/Users/gajus/Documents/dev/gajus/mightyql/dist/index.js:86
    throw new _errors.NotFoundError();
          ^
NotFoundError: Resource not found.
    at exports.many (/Users/gajus/Documents/dev/gajus/mightyql/dist/index.js:86:11)

Integration tests

Currently, unit tests only target the un-transpiled ES6 source. This is fine for testing intended behavior, but it doesn't do anything to ensure the compiled output will work (in Node or in a browser).

It would be great to run the test suite against es6/index.js and lib/index.js after they are compiled.

no babelrc / babel in packages

I'm trying to rebuild and there's no .babelrc or babel definition in this project. :/