As a rule of thumb: never throw something that isn't an Error. Please, let's keep our code a little bit more sane.
If you want to define your own errors classes, I've had no complaints when using the following module: es6-error [0]. It lets you define new error classes which extend Error without any problems.
If you don't wanna pull in a module, the following StarOverflow answer [1] shows how to define a custom error that works everywhere.
The article describes the use of captureStackTrace to grab a stack trace terminating at a given function. Based on the introduction, which several times alludes to "manipulating stack traces", I was hoping for more than a single, simple way to limit the stack frames, like maybe adjusting asynchronous calls into a synchronous-looking stack.
The only advantage to this technique over a simple try-catch-throw-new-error pattern is excluding the current stack frame, which would be confusing in most code and only useful really in a few cases like an assertion library. Even there, it would probably be nice to see the function you called on the top of the stack, since there's no throw in your own code.
It's probably worth mentioning that this is probably less performant than your standard new Error call, since the stack trace won't be expanded there until and unless you actually reference it.
If you want to define your own errors classes, I've had no complaints when using the following module: es6-error [0]. It lets you define new error classes which extend Error without any problems.
If you don't wanna pull in a module, the following StarOverflow answer [1] shows how to define a custom error that works everywhere.
[0] https://www.npmjs.com/package/es6-error
[1] http://stackoverflow.com/a/35881508/1505117