Re: pairs(t, skey) and ipairs(t, skey)

[Robert Virding <robert.virding@...>]

----- Original Message -----
> From: "Sean Conner" <sean@conman.org>
> 
> It was thus said that the Great Tim Hill once stated:
> > 
> > On Oct 1, 2013, at 6:51 PM, Luiz Henrique de Figueiredo
> > <lhf@tecgraf.puc-rio.br> wrote:
> > 
> > >> I still feel the lack of an efficient way to determine if a table t is
> > >> a sequence is a significant hole in the language/runtime.
> > > 
> > > Why would you need that? If you care that a table is a sequence, then
> > > either you have created the table and know it or you have been handed a
> > > table and can assume whoever gave you the table honors the contract with
> > > you to use only sequences. What am I missing?
> > > 
> > 
> > Seriously??? I'm stunned that you can seriously suggest "honors the
> > contract with you to use only sequences". So if a 3rd party makes an error
> > calling an API, it's ok to crash or generate random erroneous results?
> 
>   It depends upon the context of the program.
> 
>   At one point, a daemon I wrote [1] would catch SIGSEGV, log the condition,
> save its current state and exit.  And yes, it did just that.  Then I
> realized: if the program generated a SIGSEGV, it was most likely due to a
> programming error leading to subtle memory corruption and thus, the state
> I'm saving out could potentially be bogus (garbage in, garbage out).  Better
> to just log the condition and exit and skip saving any data.  Even
> better---don't bother with catching the SIGSEGV.  Instead, have a parent
> process wait for the child to exit, and report the SIGSEGV that way [2].

Interesting. This is the standard way in which errors are handled in Erlang: crash the process and let someone else (another process) catch it and clean up after it. It works.

Robert