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

[Andrew Starks <andrew.starks@...>]

On Wed, Jan 14, 2015 at 3:11 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
>> On Jan 14, 2015, at 12:49 PM, Tom N Harris <telliamed@whoopdedo.org> wrote:
>>
>> Then we could stop returning errors as nil,message and just throw exceptions.
>> Another way to encourage this is to have a standard error format that can be
>> reliably caught or re-thrown. The simplest would be to write error messages as
>> "error name: details". Anything else like errors made of two strings, tables,
>> or a new Exception type I think are unnecessarily complicated.
>>
>> --
>> tom <telliamed@whoopdedo.org>
>>
>
> Actually I'd go further and say what's missing here is a first-class error type. This would naturally solve the nil+message issues since errors could always be distinguished from non-errors with no in-band/out-band ambiguity (which is really the issues here). It would also simplify functions that only return one value, since there is no need to add an auxiliary variable to capture the error message from the second return value. This also naturally fits with exception-based handling as well, though I wont go into how this can be done here.
>
>
> --Tim
>
>

It does solve the ambiguity issue and I like that kind of idea, generally.

If your function returns a value of type 'error', then the function
that called it must check for it, just as before. This may come down
to a particular style of programming that I'm using, but this is
rarely what I want. Usually, some incoming message router needs trap
the error and reply to the client with an error reply. It is seldom
that I actually have anything more that I want to do with the error.
So, in what is the common case for me, it's simpler to view a
procedure as something that returns only one kind of value (one or
more values, of course) and errors, otherwise.

-Andrew