[Edbrowse-dev] memory error

[Karl Dahlke <eklhad@comcast.net>]

> 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.

A) So then what are the odds that "out of memory" would appear in an error message
that we really should have continued on from?
Like an undefined variable or wrong data type or something like that
where we wanted to march on but didn't?
Pretty unlikely I'd say, "out of memory" is probably in a message
when something bad / unrecoverable happens.
So plan A is pretty safe, and minimizes oodles of error messages.

B) On the other hand, what might go wrong if we do nothing here,
and wait for the next call, which will not get the object it wants
and then fail and then we close down javascript?
Probably this isn't going to cause trouble either.
We might be ok with A or B.
It might not matter terribly much.

Well as mentioned above,
B could generate lots more errors before it figures it out.
Maybe harder, during debugging, to see when the problem really started.
And I think Chriss is asking if there isn't some situation, somewhere,
like maybe:

var a = [ 2, 3, 1, 7, 9, 2, 8, 9, ...

ooddles of elements and we get a memory error
because there isn't room for the whole array,
but there might have been room for half the array,
and maybe the array just isn't created, and now there's still some memory left
for js to do some other things,
but js assumes the array is in place, but it's not, and then behaves unpredictably.
Not a seg fault, but maybe worse, maybe js sends an incomplete order across
the internet to amazon.com.
We do need to think about these things,
even though they are perhaps quite unlikely.

Anyways, if I had to cast a vote I guess I'd say to close down js on "out of memory",
to supress all the extra error messages,
and to guard against the very unlikely but possible js
misfirings that might occur if it bumps up agains the memory limit, even temporarily.

Karl Dahlke