lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




On Wed, Sep 10, 2014 at 8:39 PM, Sean Conner <sean@conman.org> wrote:
It was thus said that the Great Andrew Starks once stated:
>
> In practice, I find that it's hard to tell what is happening, especially in
> a coroutine, and especially if I use the `nil, error` approach. I generally
> like my errors to be loud and obvious and haven't had a ton of success with
> 'quietly moving on.'
>
> Soo..... what do smart people do?

  One other thing I've done.  The the one place I do call lua_pcall(), I
made sure the following function is on the stack:

        function stackdump()
          local stack = {}
          for i = 1 , 10 do
            local info = debug.getinfo(i,"Sl")
            if not info then break end
            table.insert(stack,string.format(" [%s(%d)]",info.source,info.currentline))
          end

          syslog('debug',"stack=%s",table.concat(stack))
        end

  It's enough to pin point the place of the crash.

  -spc (Then again, I'm not using the sample lua interpreter, but have Lua
        embedded in the application)


Your project sounds like a similar situation to what we're doing. Also, this is a great idea. 

Given that we're using many coroutines, I think that we're better off erring on the side of 'error' and not 'nil, error'.

Perhaps if we view every failure this way, it will support a design that scales more cleanly.

Still, there are tough calls though, like If a warning from one function causes any ambiguity about the state in another. Maybe it isn't.... just crash.

Are there interesting differences between how you think about / deal with error handling in C/C++ vs. Lua?  Accepting that the mechanisms are different, do you do more "try to recover" code in C?