2009/5/15 Sverrir Á. Berg <[email protected]>: > Hi, > I hit this while debugging on Windows and I simply ignored the assert and > continued debugging (since I was debugging a change that possibly broke some > assumptions v8 was making). I personally don't think it's nice to crash in > debug only code but if this they way you guys like it - then this is the way > it's going to be.
To me, anything that only happens after you have used the debugger to ignore a failed assert really doesn't count as having happened. There's no end to the stuff you can do to a running program with a debugger and we can't protect against it by rewriting the program. If the assert isn't valid any more after your change then it should just be removed. > Sverrir > > > On Fri, May 15, 2009 at 12:32 PM, Ivan Posva <[email protected]> wrote: >> >> Sverrir, >> >> I think we all are at a loss what you are trying to solve here (at least I >> am). >> >> The code as it is today is as follows: >> ASSERT(location_ != NULL); >> ASSERT(reinterpret_cast<Address>(*location_) != kHandleZapValue); >> >> What I keep hearing is that you are trying to protect against crashing >> the second line if location_ is NULL. Can you please explain how you >> are getting to the second line? The ASSERT on the first line will >> abort and program execution is stopped. >> >> Thanks, >> -Ivan >> >> >> On Fri, May 15, 2009 at 08:31, Sverrir Á. Berg <[email protected]> >> wrote: >> > I did not see any other replies but I understand your holding. I >> > personally >> > don't think crashing in the assert itself provides any value since >> > difference in behaviour between debug and release is bad (IMHO). How >> > about: >> > ASSERT(location_ != NULL); // as before >> > ASSERT(location_ && reinterpret_cast<Address>(*location_) != >> > kHandleZapValue); >> > Best of both worlds? >> > Sverrir >> > >> > >> > On Fri, May 15, 2009 at 2:13 AM, <[email protected]> wrote: >> >> >> >> As Søren and Kevin replied, dereferencing a null handle is going to >> >> crash anyway, so I'd like to keep this a two separate ASSERTS so it is >> >> easy to see which one of the conjuncts gets hit. >> >> >> >> >> >> http://codereview.chromium.org/113409 >> > >> > >> > > >> > > > > > > -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
