Closed trusktr closed 6 days ago
I'm torn between my desire for usability, and a desire to keep the spec lean, as this could easily be solved by a transpiler injecting new Error()
between the parens, or a very simple library. In any case it should fail loudly if a passed-in variable happens to accidentially be undefined
.
getStack(new Error())
doesn't seem particularly burdensome to me; i'm not sure it warrants special handling.
@mk-pmb the methods will throw if anything that lacks an Error internal slot is passed into them.
Theoretical use case: Someone will patch the Error constructor to count how many errors occurred in their app, so their stats will be off if we construct an error for no good reason.
@mk-pmb that'd never work regardless, because all engine-generated errors, or errors from other realms, wouldn't be counted.
It'd be nice if we could get a stack traces without having to instantiate an Error (because sometimes we want a stack traces and instantiating an Error just for that isn't semantic).
f.e. this would be nice:
Instead of
And similar for
getStackString
.