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

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

On Fri, Jan 16, 2015 at 2:19 AM, Tom N Harris <telliamed@whoopdedo.org> wrote:
> On Friday, January 16, 2015 01:11:05 AM Rena wrote:
>> Sorry, I should have been clearer: try/catch would just be nicer
>> syntax for pcall. Returning error objects instead of throwing would
>> reduce the need to use pcall (or try/catch) and thus the overhead.
>
> That's what nil,message is, essentially. A function that may fail returns a
> virtual "Maybe" type that is defined as '(nil-or-false,message)|(not-
> falsey,...)' except some functions have to use explicit nil or false because
> the other has to be in the set of valid values. But that's why adding a new
> Error type or having an out-of-band error flag (ala C errno) doesn't improve
> the language because it's only rearranging where and how the error is stored
> without changing the logical way that it is raised or caught.
>
> --
> tom <telliamed@whoopdedo.org>
>


So many good reads in this thread...

>From before the fork, Willian Ahern Said

The only unequivocally useful approach I've found is to try to keep code
which can fail as localized as possible. And to design my code so that the
vast majority of the logic is organized and implemented as routines which
have no failure mode. This works equally well in C, C++, Lua, and every
other language, regardless of the error handling strategy. You don't need to
worry about errors when there can't be any ;)
----

number_of_places_that_fail_to_produce_a_usable_result >
places_where_you_want_to_do_something_about_it

...by a lot, in my limited experience.  If you always error, you can
pretend that errors never happen, until you can't. In a garbage
collected language, the places where you need to clean the state up
are pretty limited, so this may be more true of Lua than of C, or
whathaveyou.

`return nil, error_msg` forces you to write more code every time you
call that function.

-Andrew