Standardizing out-of-memory and stack-depth-exceeded errors?

Brendan Eich brendan at mozilla.com
Wed Mar 23 11:36:46 PDT 2011


On Mar 23, 2011, at 1:06 AM, Juriy Zaytsev wrote:

> On Tue, Mar 22, 2011 at 12:07 PM, Joshua Bell <josh at lindenlab.com> wrote:
> I was noodling with a (toy) compiler-to-JS for a (dead) language that supports error handlers for two boundary conditions - stack depth exceeded & out of memory - and noticed that the relevant behavior in JS is not standard across browsers. Has there been any discussion around standardization of errors thrown when limits of the script execution environment are hit? (Searching the archives didn't yield hits, but my search-fu may be weak today.)
> 
> From briefly testing the boxes on my desk:
> 
> stack depth:
> function a() { return a() + 1; } a();
> 
> * IE9: Error, message: 'Out of stack space'
> * Firefox 4: InternalError, message: 'too much recursion'
> * Safari 5: RangeError, message 'Maximum call stack size exceeded'
> * Chrome 10: RangeError, message: 'Maximum call stack size exceeded', type: 'stack_overflow'
> * Opera 11: Error, message: 'Maximum recursion depth exceeded'
> 
> RangeError makes most sense here, imo. It does after all "indicates a numeric value has exceeded the allowable range" (15.11.6.2) even if this "numeric value" is something internal. Standardizing (or agreeing upon) RangeError across implementations wouldn't solve much of course, since it could be RangeError caused any of the other cases where RangeError occurs. Parsing message for "stack" or "recursion" would help, but that's just ugly and fragile.

Disagree. RangeError might rather be called ValueError based on how it is used. There is no over "value" in a recursively deep program, e.g. Ack(4,5) given

function Ack(m, n) {
    if (m == 0)
        return n + 1;
    if (n == 0)
        return Ack(m - 1, 1);
    return Ack(m - 1, Ack(m, n - 1));
}

that can be cited by the error message. Think about the developer's point of view. Which argument is to blame? Or is Ackermann's function to blame? The engine won't know.


> Firefox's InternalError looks like something non-standard. I wonder why they don't just throw Error.

This is *all* non-standard! There is no normative spec.

Picking odd-Firefox-out when the other browsers split into pairs and disagree between Error and RangeError just confirms that. It does not argue that we should jump on one of *two* bandwagons.

This is a minor point, but I am strongly against RangeError being used for an internal recursion limit that may be OS-dependent.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110323/9922adaf/attachment-0001.html>


More information about the es-discuss mailing list