[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.3.0 (final) now available
- From: Tom Sutcliffe <tomsci@...>
- Date: Wed, 14 Jan 2015 23:40:30 +0000 (GMT)
On 14 Jan, 2015,at 10:30 PM, Javier Guerra Giraldez <email@example.com> wrote:
On Wed, Jan 14, 2015 at 3:49 PM, Tom N Harris <firstname.lastname@example.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.)
In short, please don’t change anything in this area, I like it fine just how it is :-)