Re: [ANN] Lua 5.3.0 (final) now available

On Wed, Jan 14, 2015 at 3:49 PM, Tom N Harris <telliamed@whoopdedo.org> wrote:
If library writers are eschewing throwing errors to not inconvenience users
who aren't properly using pcall, then that contributes to the problem. Being
more assertive (pun intended) will drag people kicking and screaming into
proper defensive programming techniques.

I think you're elevating your preferences to "proper techniques".

I happen to prefer the nil,msg pattern for most cases, and to
explicitly use asert() when i want to signal errors. pcall() (and, to
a lesser extent try/catch) are too similar to COMEFROM to my taste, so
i prefer to have only one, at most two levels of pcall() surrounding
most of the main loop or core/plugin interfaces, or so on. i find
more readable to have error-handling code right there where the error
is reported (with the nil return)

Yes, me too. I’ve always been happy with how Lua handles nil and errors. You can always wrap your call in an assert() to convert a nil result to an error, if that fits your code flow/style better, but it’s much less convenient to convert an error to a nil. (Python’s insistence in trying to make everything use errors just plain aggrevates me). My background is from environments where setjmp/longjmp were considered expensive operations so I may be a little biased there, I suppose. As for making errors a proper type, again I like the fact that Lua doesn’t prescribe a particular type, and that if you want to you can call error() with pretty much anything. It means you have great flexibility in how you use errors, and having the standard libraries not use them at all means they will not conflict with whatever system you pick.

(Fun fact: error(nil) doesn’t print an error message if you run it in the interpreter even though xpcall(error, debug.traceback, nil) does return nil plus a stacktrace in the second result so you’d expect it should print something.

Sllightly more understandable fun fact: calling error with a non-string means you won’t get stack traces out of the standard xpcall(fn, debug.traceback, ...) pattern and you have to roll something a little more sophisticated.)

Lua’s slight wrinkle with nil and false both being “falsey” makes far more sense than the equivalent rules in say _javascript_ or Python (I do occasionally trip myself up with zero being truthy in Lua but falsey in C, but on balance I wouldn’t want it to be falsey in Lua, it would be too messy. I’m just too used to C sometimes.). Even the distinction of none vs nil in the C API never bothered me, since it so rarely matters anyway. Returning non-nil values following a nil never seemed illogical to me - I don’t find the arguments against such a construct to be that compelling. The only thing I think is a bit messy is integer-indexed tables with nil ‘holes’. Careful wording around ‘well-formedness’ in the table documentation gets you so far, but I never did figure how for instance that was supposed to work with the __ipairs metamethod. Ah: I see that is deprecated in 5.3 - that simplifies matters! So I don’t think I have any real compliants there either.