Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

[Sean Conner <sean@...>]

It was thus said that the Great Philipp Janda once stated:
> Am 21.01.20 um 18:14 schröbte Sean Conner:
> >It was thus said that the Great Xavier Wang once stated:
> >>Sean Conner <sean@conman.org> 于2020年1月21日周二 
> >>下午1:38写道：
> >>>
> >>>   My thoughts for returning an error number instead of a string is that 
> >>>   the
> >>>number is easier for error handling and if I want to print out a string, 
> >>>I
> >>>can use a wrapper for strerror() at that point.  But aside from error
> >>>reporting, all three APIs are similar enough to get a feel for what might
> >>>make the minimum library.  Here's what I have so far (excluding the error
> >>>reporting):
> >>
> >>I have my own module for directory functions[1], and I found that if
> >>you want cross platform native directory operations, you can not
> >>always get errno. Windows has its own routines and error codes for
> >>that.
> >
> >   The intent was to provide a API (and/or library) for the minimal
> >"batteries included" for Lua, but I can see this might be an uphill battle
> >(nothing terribly surprising there).
> >
> >   As for Windows, I'm not specifically looking to return errno (it *is*
> >defined for C, and there are a few C functions that do set it) but some
> >error number for error handling.  The string is handy if all you want to do
> >is just print a message but if you want to do something based upon the type
> >of error, some numeric value is the best way to handle that.  In fact, I
> >don't think I even mentioned errno at all.
> 
> Plain errno is pretty useless for portable error handling even when 
> considering POSIX platforms only. For instance, what does a result of 17 
> tell you about the failure? 

  On Linux?  That the file exists when it shouldn't (EEXISTS).  I already
have a module (loadable via LuaRocks) that enumerates errno values, and can
be used like:

	errno = require "org.conman.errno"

	err = some_function()
	if err == errno.EINTR then
	  ...
	else
	  log("some_function returned %s",errno[err])
	end

  I don't think it would be that hard to include such a module.  

> Obviously it gets more complicated when we 
> include non-POSIX platforms. It seems that the common approach is to map 
> some operating system specific error code (which could be errno) to some 
> error condition you want to check for. This mapping is not necessarily 
> one-to-one, so the APR uses function macros to check for error 
> conditions, and C++11 has `std::error_code` that you can compare to 
> `std::error_condition`s. We probably should figure out how Lua libraries 
> are supposed to handle this, otherwise the proposed minimal directory 
> API can't even be used to implement a portable `mkdir -p`, because you 
> can't say whether `mkdir` failed because a path component already existed.

  Fair enough.

> The issue also applies to the current Lua standard library which at the 
> moment is very `assert()`-friendly but can't really handle errors in a 
> more constructive way.

  Lua 5.3 does document the third return from some calls like file:read()
and io.open()---which is the numeric error value (errno) in addtion to the
falsey first return value and the error message string as the second return
value.  I'm not terribly happy with that, but my proposals have been
following that scheme.

  -spc