Re: Dealing With Errors in Lua

[Rena <hyperhacker@...>]

On Fri, Sep 27, 2013 at 9:51 PM, Sean Conner <sean@conman.org> wrote:

> In fact I notice that io.open in particular *does* appear to be returning

> some type of error code, though the manual doesn't mention this. (At least
> not in the description of io.open, but maybe somewhere?)

  Actually:

        Lua 5.1, section 5.7:

        Unless otherwise stated, all I/O functions return nil on failure
        (plus an error message as a second result and a system-dependent
        error code as a third result) and some value different from nil on
        success.

        Lua 5.2, section 6.8:

        Unless otherwise stated, all I/O functions return nil on failure
        (plus an error message as a second result and a system-dependent
        error code as a third result) and some value different from nil on
        success.

  The value comes from errno, which is part of ANSI C.  The actual text
comes from the Standard C function strerror().

I knew they must be there somewhere. :)
 

 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?)

Well, aside from EDOM and ERANGE, what else to include?  My own errno
module [1] uses a ton of #ifdef's (and yes, it's heavily Unix influenced,
but then again, I primarily use Unix).  And even though I define a large
number of errors, I tend to only use a few:

        EINTR           - a system call was interrupted
        ETIMEDOUT       - an operation timed out

  and sometimes EINVAL (invalid paramter to a system call).  And that's
about it.  Most of the time, as long as I can get a human readable version,
I'm happy.

Well, that's largely the point of this discussion :) there are a lot more error cases than EDOM, ERANGE, EINTR and ETIMEDOUT can really cover, as [2] shows; the question being if one can come up with a list that would cover most cases that most scripts will encounter.

> I've often also felt like Lua could stand to have a standard "warning"
> function. By default warning() might be something like:
> function warning(msg, ...) io.stderr:write(msg:format(...) .. '\n') end
> but the application could redefine it to send the messages elsewhere or do
> nothing.

  You can do that now with error().

How so? I don't know of any way to resume 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.

[1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/errno.h.html

[2] http://www.laufenberg.ch/lua/dump.log


--
Sent from my Game Boy.