Description
The thrown error here swallows the stack trace of the original error, making it difficult to debug.
Expected Result
The stack trace (or perhaps the log) should reflect where the original error actually occurred.
Actual Result
The only stack trace shown is from the catch block
Reproduction
https://codesandbox.io/s/x-state-swallowed-stack-ytvig
Additional context
I'm not sure if this is an actual issue, but I had to enter a node inspector session when using xstate/test in order to find out what was actually causing this issue.
Perhaps the original stack could be logged, or a library like chained-error could be used?
We are going to rethink how thrown errors are handled in the upcoming v5. In SCXML those would be converted to error.execution events, but I'm not sure if we want to follow that. @davidkpiano have your thought about this recently by any chance?
Yes, so error traces should be preserved and carried through to the ultimate error.execution event. I'll look into this.