Re: Dealing With Errors in Lua

[Sean Conner <sean@...>]

It was thus said that the Great Rena once stated:
> On Fri, Sep 27, 2013 at 9:51 PM, Sean Conner <sean@conman.org> wrote:
> 
> >  False, if Windows claims to support ANSI C---errno.h is *part* of a
> > standard implementation of C.  Now, Windows might not support much beyond
> > EDOM and ERANGE (I see nothing about EILSEQ in the ANSI C standard) but it
> > is there.  And strerror() should return a human readable string given an
> > error message.
> >
> Right, I got a bit mixed up there. errno.h has to be available, but might
> not be very useful with only two or three error codes. (The reference I
> used[1] says EILSEQ is part of ISO C, maybe not ANSI C?)

  EILSEQ is C99, not C89.  So we're both right.

> >   You can do that now with error().
> >
> How so? I don't know of any way to resume after an error().

  Ah, resuming after an error.  

> > So I asked one of my college instructors what to do.  His reply, as
> > distateful as it seems, can't really be argued with: If you don't know how
> > to handle the error, then don't check for the error.
> >
> This is good advice, but my concern is less about how to handle an error,
> and more how to represent it to the code that does handle it.

  Okay, let's pick one at random---the one in lmathlib.c, "wrong number of
arguments".  First, some code:

	function()
	  return math.random(1,8,3)
	end

  and the error we get back:

	lua: /tmp/y.lua:2: wrong number of arguments

  I know how to handle it, but getting the program to handle it is another
matter entirely.  How to handle this?  Fix the offending code.  How would
you deal with it, assuming you got some integer value you could quickly
check?

I could go through more errors, but basically, they will all fall into one
of four catagories (in no particular order) [3]:

    1. programming errors, like EBADF (not an open file, or the operation
       couldn't be done given how the file was open originally) or EINVAL
       (invalid parameter) that need to be fixed, but once fixed,
       neverhappens again;

    2. it  can be fixed, like EACCESS (bad privileges) or ELOOP (too many
       symbolic links when trying to resolve a filename) but that the fix
       has to happen outside the scope of the program, but once fixed, tends
       not happen again unless someone made a mistake;

    3. better exit the program as quickly and cleanly as possible because
       something bad, like ENOMEM (insuffient kernel memory) just happened
       and things are going bad quickly. Depending upon the circumstances, a
       fast, hard crash might be the best thing to do;

    4. and finally, the small category of errors that a program might be
       able to handle, like ENOENT (file doesn't exist) depending upon the
       context (it could then create the file, or ask the user for a
       different file, etc.).

  #1-3 are in the class of "print an error message and stop" (and error()
will give you something you can print) while #4 is something that could be
handled (and is handled badly if you use exceptions for this class, in my
opinion).  And in looking over the possible Lua errors [2], I don't think
there are any in class #4.

  -spc (Dealing with an error at work, where a "this should never happen"
	happened ... )

> [1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/errno.h.html
> 
> [2] http://www.laufenberg.ch/lua/dump.log

[3]	http://boston.conman.org/2009/12/01.2