From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 4D7737853B for ; Mon, 24 Feb 2014 02:26:19 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q58so4459289wes.38 for ; Mon, 24 Feb 2014 02:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=K0/EwXJ99kREqdaQoE0uRSh0qAVEh6dHig0OvMtZRfM=; b=R1QxIEBzQ2QAYXp+yMla4mGi3sYLZ3Lq5bgeyME5wwjQF6ZI9fcX+K8Itjwi5BCLla 4VlPyXBow+KEpm1BAQpWmUbvL4KxxrurZG+C4JQEl50FWMnoeObJ+PM3Jc7eioMR5g9L CZGD3/runIJb+hAbWE9zQ2J4K/SfFfTEG9m7CUDlTtuU/0h4fRcYcpwPMiWMf19H7RVv c1XNS9+/iAzW058/C6gqDx9yQpJjLpSBmftTRRPAP7Q/Rxrecs3+I/7wkcUvp2TsOa6G cWScPWtno+z8zPl+1IRTeTJxsNMUdrkFBAnRcZn5zCCCTgyZS0t8LSaYNXhYpHHNfTr7 JzJQ== X-Received: by 10.180.98.165 with SMTP id ej5mr13232430wib.33.1393237519908; Mon, 24 Feb 2014 02:25:19 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id ff9sm22894384wib.11.2014.02.24.02.25.18 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 24 Feb 2014 02:25:19 -0800 (PST) Date: Mon, 24 Feb 2014 10:25:04 +0000 From: Adam Thompson To: Chris Brannon Message-ID: <20140224081352.GA3585@toaster.adamthompson.me.uk> References: <20140123175711.eklhad@comcast.net> <20140223231606.GE15819@toaster.adamthompson.me.uk> <8738j95qty.fsf@mushroom.PK5001Z> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8738j95qty.fsf@mushroom.PK5001Z> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] memory error X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 10:26:19 -0000 On Sun, Feb 23, 2014 at 03:53:13PM -0800, Chris Brannon wrote: > Adam Thompson 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.