[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: suggestion on error returns, especially in callbacks from C?
- From: Sam Roberts <sroberts@...>
- Date: Fri, 1 Dec 2006 18:21:02 -0800
My understanding is the lua library convention is that error() is only
called for things that coding errors (using a table as a function, wrong
arg types, etc.), but not for errors that are theoretically not caused
by the code, those return nil,"message". So, if you want to handle
errors non-locally, its the callers responsibility to call assert.
Ok, what about in callbacks from C libraries?
I notice both the PIL
http://www.lua.org/pil/29.2.html
and LuaThreads use lua_call(), so errors will longjmp very far....
In the case of expat, there is a good chance expat does not deal
well with being longjmped out of (though perhaps it does), and will
leak resources as the error propogates up back to lua code.
In the case of LuaThread, if a thread function errors, I think lua
calls lua_atpanic() and aborts...
Is this the right thing to do for a library?
I wonder because I am binding lua to a network protocol library, and it
calls out to lua to deliver packets, and I am wondering what to do...
- lua_pcall(), and log then suppress errors?
- lua_pcall(), and rip down the network connection?
- lua_pcall(), and call a LUA recovery function, so users of the lib
can configure error response in lua?
- lua_call, which will call atpanic and abort? And if the user doesn't
like this, the first thing they should do in their lua callback
function is do a pcall!
Any other suggestions?
Reminder - I'm building a library, not an app, I want to provide
mechanism, not policy.
Sam