lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 


I'm still not buying this, but..
let's say I would. :) Would you be pleased with a userdata-based 'enum' thingy, that's class aware. That is, you can compare such values only with others of the same enum class (think integer type, with families of values).
Implementing this approach with current stock Lua might be hard, though, but I see it as a 'missing link' that Lua ought to have. 

-ak

22.12.2004 kello 07:48, Mark Hamburg kirjoitti:
That is certainly the way to deal with this within Lua as it stands, but the
conventions used in FinalizedExceptions and for routines like io.open avoid 
having a separate success code by overloading the first result.

Mark

on 12/21/04 9:10 PM, Rici Lake at lua@ricilake.net wrote:



On 21-Dec-04, at 9:04 PM, Mark Hamburg wrote:


The following is a non-ideal example, but the idea is that if one
adopts the
convention that libraries should return errors rather than throwing
exceptions (see http://lua-users.org/wiki/FinalizedExceptions), then it would help to have a way to express errors when false and nil are valid 
results.
Surely the pcall convention (first result is the success indicator) does 
just that?


function itemExists( db, itemKey )
    -- Returns true if database db contains an item with the
    -- given key. Returns false if the database does not contain
    -- an item with given key. Returns error in the event of an
    -- error reading the database.


Which this example is perfect for:
 true, true (or perhaps some more useful value)
 true, false -- no such key
 false, "Wrong password, bozo" -- database error


Example usage:

exists = error_assert( itemExists( db, itemKey ) )


where error_assert is (in lua 5.1, I think):
 function (success, ...)
   if success then return ...
    else error((...))
   end
 end