tc39 / proposal-error-stacks

ECMAScript Proposal, specs, and reference implementation for Error.prototype.stack / System.getStack
https://tc39.github.io/proposal-error-stacks/
MIT License
168 stars 13 forks source link

standard for nested stack traces (Error.prototype.cause) #32

Closed andykais closed 4 years ago

andykais commented 4 years ago

Hi, not sure if this can be bolted on to this proposal, but there are libraries like verror out there that allow errors to be stacked. This is handy when you propogate an error through a system and want to attach more context to it as it bubbles up. Could we attach another standard method to the error class that allows us to optionally see if there is a parent error attached to an error instance? E.g.

function x() {
  throw new Error('error in x')
}

function y() {
  try {
    x()
  } catch(e) {
    throw new Error('error in y', e)
  }
}

function printError(e) {
console.log(e.stack)
  if (e.cause) {
    console.log('caused by')
    printError(e.cause)
  }
}

try {
  y()
} catch(e) {
  printError(e)
}
ljharb commented 4 years ago

You may be interested in https://www.npmjs.com/package/es-aggregate-error, which will be in the language soon?

This proposal is currently two parts; the first is documenting/specifying the existing stack property; the second is adding static methods to provide a structured representation of the stack.

(Separately, I think that your idea would have to be a separate proposal; I think adding more things onto Error.prototype is unlikely; and I'm not clear on why this needs to be in the language at all)

andykais commented 4 years ago

ah interesting. I will look into it. My point was to standardize the shape of an error cause. This would allow unrelated libraries to consume errors with parent errors. (java has this as a standard feature for instance). If it doesnt fit in this proposal, then it doesnt fit though. Oh well