On Sun, Feb 23, 2014 at 03:53:13PM -0800, Chris Brannon wrote: > Adam Thompson <[email protected]> writes: > > > That's really annoying. I've got nothing against taking actions based on > > the > > error number as (if I understand the mechanism correctly) > > this is dependant on the type of error. > > However, doing things based on the error message (which I think comes from > > exceptions, user thrown or otherwise) seems a bit more fragile to me. > > It does come from an exception. When out-of-memory is encountered > during script execution, this is converted to a JS exception. If it > isn't caught, my_ErrorReporter sees it as "uncaught exception: out of > memory".
Yes, I thought so. > You're right. Acting on the error message is fragile, and I don't like > it either. On the other hand, I like propagating errors to unrelated > parts of the program even less. Yes, there's a good chance that we'll > catch the error as soon as we call another JSAPI function, but I think > there's also a chance (however slight) that we won't. E.G., suppose the > script throws the out of memory exception and a bunch of memory gets > reclaimed afterword. This will probably lead to completely unrelated bugs in > the rest of the JavaScript executed in this context. I agree, I just wonder if there's a nicer way to do this. > So it's a trade-off, and I vote for trying to catch the error as soon as > possible. I just added a test for this case in jsrt and it turns out that (as suspected) the out of memory exception is thrown in one script, the rest of js can carry on and thus partial arrays etc hang around. Much as I'd like to think js programmers would handle this, I doubt it. Cheers, Adam. _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
