tag:blogger.com,1999:blog-2683431904392903776.post4776889205167299101..comments2023-10-07T00:40:18.776-07:00Comments on V8 JavaScript Engine: One small step for Chrome, one giant heap for V8Unknownnoreply@blogger.comBlogger2125tag:blogger.com,1999:blog-2683431904392903776.post-75663111244868327202017-02-14T10:03:49.718-08:002017-02-14T10:03:49.718-08:00i was just about to leave the same comment! Yes th...i was just about to leave the same comment! Yes this would be super helpful when debugging such issues: the experience now is painful if you don't already know the source of the infinite recursion.Unknownhttps://www.blogger.com/profile/15684956143044651408noreply@blogger.comtag:blogger.com,1999:blog-2683431904392903776.post-17064548123582638232017-02-09T15:30:53.369-08:002017-02-09T15:30:53.369-08:00This debugging feature is probably wonderful when ...This debugging feature is probably wonderful when you need it. Can you add a similar debugging feature for call stack size limit exceeded errors, breaking when it is too close?<br />A "smart" feature would probably be to break early only if the user refreshed the same page following a call stack size limit exceeded error. Perhaps a tristate option would be, "no" (just throw an error), "auto" (which acts like my ""smart" feature" suggestion) and "always" (which always breaks when close to the limit), the default being "auto".PhistucKhttps://www.blogger.com/profile/06666208790643226861noreply@blogger.com