
JavaScript Errors and Stack Traces in Depth - lucasfcosta
http://lucasfcosta.com/2017/02/17/JavaScript-Errors-and-Stack-Traces.html
======
TheAceOfHearts
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.

[0]
[https://www.npmjs.com/package/es6-error](https://www.npmjs.com/package/es6-error)

[1]
[http://stackoverflow.com/a/35881508/1505117](http://stackoverflow.com/a/35881508/1505117)

------
couchand
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.

------
c0achmcguirk
The page seems to have been slashdotted....or HackerNewsed. Google cache is
here [0].

[0]
[http://webcache.googleusercontent.com/search?q=cache:vM3Pd-w...](http://webcache.googleusercontent.com/search?q=cache:vM3Pd-
w-d_MJ:lucasfcosta.com/2017/02/17/JavaScript-Errors-and-Stack-
Traces.html+&cd=1&hl=en&ct=clnk&gl=us)

