Re: Dealing With Errors in Lua

[Paul K <paulclinger@...>]

> Unfortunately, implementing resource cleanup in vanilla C is expensive.  I haven't looked carefully at Alex's implementation, but, from his notes, it sounds like every entrance into a scope containing finalizers will require a luaD_pcall.  So while the patch can often save you the cost of creating temporary closures, there's still quite of bit of implied overhead.

I believe so, according to my reading of the patch and the
description: "(6) The standard luaD_pcall function is used. This
should allow it to work in C++, delphi, C, anything. Longjmps/Setjmps
are not required. Two stack positions are used per guard/finalize, and
a bit of C stack."

You can implement the same thing with pcalls, but the implementation
will look similar to the first try/catch example. So, it's a syntax
sugar around pcall, but with nice properties as pairings are easy to
see and they are close to each other.

Paul.

On Sun, Sep 29, 2013 at 12:21 AM, Sven Olsen <sven2718@gmail.com> wrote:
> Thanks for the links!  Alex's finalize patch really feels like it ought to
> be posted somewhere more visible -- from what I can tell, it looks like a
> fairly nice implementation.
>
>> I like guard/finalize syntax better than try/catch:
>> http://lua-users.org/lists/lua-l/2008-02/msg00243.html (this event
>> includes a patch against one of Lua 5.1 versions).
>
>
> Yeah, I concur.  If you're going to add a new exception handling feature to
> the language, I think the semantic to choose would be something like Alex's
> finalize -- a convenient, exception-safe way of releasing resources.
>
> Unfortunately, implementing resource cleanup in vanilla C is expensive.  I
> haven't looked carefully at Alex's implementation, but, from his notes, it
> sounds like every entrance into a scope containing finalizers will require a
> luaD_pcall.  So while the patch can often save you the cost of creating
> temporary closures, there's still quite of bit of implied overhead.
>
> Piggybacking on C++ destructors, for those of us who have the option, still
> feels likely to be a better way of solving the same problem.  Compared to
> nested luaD_pcalls, stack unwinding should be relatively cheap; and writing
> a handful of C++ resource wrappers is far easier than trying to maintain
> such a significant Lua mod.
>
> -Sven