The debugger's JS API is supposed to be just that, an API to build upon. You'd expect the C++ API to crash on CHECK failures as well, right? Also, I wouldn't call illegal access exceptions great experience for embedders either. Maybe we can turn select ones into more descriptive exceptions?
Yang On Fri, Oct 16, 2015 at 11:05 AM Ben Noordhuis <[email protected]> wrote: > On Thu, Oct 15, 2015 at 3:15 PM, Michael Starzinger > <[email protected]> wrote: > > TL;DR: I propose to convert (almost) all RUNTIME_ASSERT into CHECK > macros. > > > > We make heavy use of RUNTIME_ASSERT to check preconditions for our > runtime > > functions (i.e. everything in src/runtime/runtime-*.cc files), which in > turn > > will cause an "illegal access" string to be thrown if the precondition is > > violated. As far as I am aware, there are only three cases of how > > preconditions could be violated: > > > > 1) Builtin functions that use runtime calls have a bug. > > 2) Compilers that directly emit runtime calls have a bug. > > 3) Third-party code is running with --allow-natives-syntax and is abusing > > runtime calls. > > > > For all three cases I think we should not continue executing (i.e. > throwing > > an exception), but instead should abort execution immediately and crash > hard > > (even in release mode). This would give us feedback about bugs for (1) > and > > (2) happening in the wild. There is a small set of runtime functions > (i.e. a > > white-list of three runtime calls) that ClusterFuzz uses while generating > > test cases, these three deserve special treatment and would continue to > fail > > gracefully. > > > > Subsequently the --stack-trace-on-illegal can be deprecated as well, > because > > its only purpose is to make the hidden asserts more verbose, which actual > > crashes at the check site would accomplish implicitly. > > > > Random data point: I have a permanent breakpoint on > > Isolate::ThrowIllegalOperation in my gdbinit file because I regularly > wasted > > about 10 minutes tracking failures back to these asserts on several > > occasions already. > > > > Comments? Thoughts? > > > > Best regards, > > Michael > > Would this also affect the illegal access exceptions you get when you > call e.g. Debug.scripts() before Debug.setListener()? If it does, > that's arguably not a great user experience for embedders. > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
