catching of VU panics

[mstoykov]

No description provided.

[codecov-io]

Codecov Report

Merging #1697 into master will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1697      +/-   ##
==========================================
+ Coverage   72.31%   72.33%   +0.01%     
==========================================
  Files         176      176              
  Lines       13536    13538       +2     
==========================================
+ Hits         9789     9793       +4     
+ Misses       3134     3132       -2     
  Partials      613      613              

Flag	Coverage Δ
ubuntu	72.30% <100.00%> (-0.01%)	⬇️
windows	70.88% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
js/runner.go	80.45% <100.00%> (+0.32%)	⬆️
js/modules/k6/http/request.go	80.64% <0.00%> (-0.07%)	⬇️
cmd/cloud.go	6.85% <0.00%> (+0.07%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7586ddf...d1db643. Read the comment docs.

[mstoykov]

This supersedes #1665

[mstoykov]

For the record this code resets the stack and other stuff to the previous values if there is a panic (even if the code below panics again) to what it was before a function was called and calling a Callable basically calls this.

So unless this code panics in the middle the state of the Runtime should be "somewhat" restored to the previous one. Obviously any changes to global variables will stick.

And if the panic in somehow has gotten the non goja stack but for example some internal to k6 state in a bad state that will lead to problems. I can't figure out a way to break the goja stack in my first few tries and ... I can't remember anything in k6 that will have such a problem so it seems safe.

[na--]

LGTM. Please squash when merging and close #1601 and #1665