[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: suggestion on error returns, especially in callbacks from C?
- From: Sam Roberts <sroberts@...>
- Date: Tue, 5 Dec 2006 12:17:55 -0800
On Tue, Dec 05, 2006 at 04:28:15PM -0200, Roberto Ierusalimschy wrote:
> I am sorry for the bad information. Actually, I found "documented"
> somewhere that it was *not* safe to longjmp Expat, so the real library
> (luaexpat) uses lua_pcall to call Lua handles. The code in the book was
> (maybe over) simplified. (The real code is a little tricky, because once
> there is an error it must stop calling other handles, but there is
> no way to stop Expat.)
Ok, then what is the best-practice for callbacks from C that call into
lua? Obviously, if the library is longjmp-safe, just using lua_call() is
best, but most libs aren't jmp safe.
What do you all suggest? As a specific case (not mine, but close),
imagine an xml-rpc server, mostly implemented in C, but where the
individual requests are handled by lua_[p)call().
- use lua_call()?
In this case a lua fn that errored would end up aborting in a fairly
traumatic way, but the writer of the callback has the opportunity to
local r = pcall(function(...)
-- ... do stuf that might error
-- ... your choice, as app designer, what do you want to do?
- use lua_pcall(), and synthesize an xml-rpc error response? And log the
- use lua_pcall(), and terminate the connection?
I am leaning towards just doing a lua_call(). The user of the library
then has total control over the behaviour, and I don't have to make
any decisions for them. If they fail to make a good decision, they will
realize this, because they'll get a core dump.