Re: Exceptions (was Re: Custom extensions to Lua)

[Mark Hamburg <mhamburg@...>]

Some quick notes on my experiences with error handling in Lua and
elsewhere...

* Exceptions are a pain from the standpoint that at some point, almost
anything can throw. This can make one paranoid when trying to write
exception safe code. This is particularly true in C++, but it's true in
pretty much anything with exceptions.

* If an API might throw an exception, then having it also have the option of
reporting errors in another way potentially complicates the code. Now you
have multiple error handling paths. I understand the difference between
io.open failing to find the file and not being given a path to a file, but
the policy can easily become fuzzier as one moves up and the cleanup code
gets trickier.

* The most common place where exception handling comes in seems to be one of
scope closure. Having a way to say "execute this code on exit whether we
return or throw an exception" would probably clean up a lot of the code
paths listed above. A lot of it can be addressed simply through garbage
collection, but that makes closure non-deterministic.

* nil + error message is ugly to propagate particularly if a function has
multiple results. It leads to code such as the following:

    local image, quality = get_image_and_quality()
    if not image then
        return image, quality -- actually nil, message
    end

The ugliness is that quality isn't quality in the return statement. It's the
error message. One can turn this into an exception using assert, but that
then takes one out of the nil + message domain.

This could be resolved with a non-local return mechanism for Lua that would
let one build a function to do the following:

    local image, quality = return_if_nil( get_image_and_quality() )

Mark