Re: lua 5.2 beta & error level

[Eduardo Ochs <eduardoochs@...>]

On Thu, Nov 3, 2011 at 11:42 AM, liam mail <liam.list@googlemail.com> wrote:
>
> On 3 November 2011 13:05, Ashwin Hirschi <lua-l@reflexis.com> wrote:
> >
> > Looking at the "error" function in Lua 5.2 beta, would it not be more useful
> > (and friendly) if the traceback that's being generated would also take the
> > "level" parameter into account?
> >
> > For example, this scripted scenario:
> >
> >        -- public primitive
> >        function go4it(str)
> >                down1(str)
> >        end
> >
> >        -- consider these "internal"
> >        function down1(str)
> >                down2(str)
> >        end
> >
> >        function down2(str)
> >                if type(str) ~= "string" then
> >                        error("strings only, please!", 4)
> >                end
> >        end
> >
> >        -- some (separate) client/user's code
> >        print "starting..."
> >        go4it(1000)
> >        print "done."
> >
> >
> > prints the "starting..." message and then the following alert:
> >
> >        errorlevel.lua:20: strings only, please!
> >        stack traceback:
> >                [C]: in function 'error'
> >                errorlevel.lua:14: in function 'down2'
> >                errorlevel.lua:9: in function 'down1'
> >                errorlevel.lua:4: in function 'go4it'
> >                errorlevel.lua:20: in main chunk
> >                [C]: in ?
> >
> >
> > The very first line correctly identifies the line (20) in the source code
> > I'd like it to (and indicated when calling error with level 4).
> >
> > However, the traceback begins with 4 "extra" lines that'll likely confuse
> > the person who's only seeing the client code... (while also exposing
> > internal/implementation details I'd like to hide!).
> >
> > Please note that in "real life" the client code is much more complicated and
> > often nested. So, having a traceback definitely does make sense.
> >
> > I'd just like it to be a bit more to the point when I've indicated as much
> > to the error function. Isn't that the function of error's level parameter in
> > the first place?
> >
> > What are your thoughts?
> >
> > Ashwin.
> >
> >
> Why not overwrite the traceback function and strip the message down to
> the information you want to reveal? Personally when I ask for a
> traceback (which is what error is doing) I want to see the traceback
> :)
>
> Liam

By the way: what do you guys use when you have to define your own
traceback functions? Let me be more precise... most of the work
that is involved in printing a traceback when an error happens is
done by db_errorfb, see:

  http://www.lua.org/manual/5.1/manual.html#pdf-debug.traceback
  http://www.lua.org/source/5.1/ldblib.c.html#dblib
  http://www.lua.org/source/5.1/ldblib.c.html#db_errorfb

The Lua function errorfb_line below is a reasonably faithful
translation of a part of db_errorfb,

  errorfb_line = function (ar)
      local s = "\t"
      local p = function (...) s = s..format(...) end
      p("%s:", ar.short_src)
      if ar.currentline > 0 then p("%d:", ar.currentline) end
      if ar.namewhat ~= ""  then p(" in function '%s'", ar.name) else
        if ar.what == "main" then p(" in main chunk")
        elseif ar.what == "C" or ar.what == "tail" then p(" ?")
        else p(" in function <%s:%d>", ar.short_src, ar.linedefined)
        end
      end
      return s
    end

but my translation of the rest - a gross simplification, actually - is
not worth showing, except for this part...

  errorfb_lines = function (a, b, step, f)
      local T = {}
      for level=a,b,(step or 1) do
        T[#T+1] = (f or errorfb_line)(debug.getinfo(level))
      end
      return table.concat(T, "\n")
    end

I'd like to stop reinventing the wheel (and making it square). Any
pointers/suggestions?

  Cheers,
    Eduardo Ochs
    eduardoochs@gmail.com
    http://angg.twu.net/