Re: Lua 5.3: assert non-string values in #2 cause `(no error message)`-style error message

[Andrew Starks <andrew.starks@...>]

On Mon, Oct 20, 2014 at 1:55 AM, Philipp Janda <siffiejoe@gmx.net> wrote:

Am 20.10.2014 um 06:46 schröbte Andrew Starks:

local success, p_res = assert(p(11))
--> C:\lua.exe: (no error message)
```

I don't know if this has broad potential for others, or not, but an error
would be welcomed here, as well. This time for having any value that is not
a string or `nil` in assert's second argument would have saved me hours of
head scratching.

It's not `assert`'s fault. `error{}` without an explicit `pcall` has the same "(no error message)" effect. (And some people _want_ to use `assert` with non-string error messages ...)

Not having a line number/file name was very...difficult.

The place where bad things happen is the `msghandler` function in `lua.c`. It replaces any non-string errors with strings, but also doesn't add a stack trace in this case (which it could since the original error value is discarded anyway).

You could add

        msg = lua_tostring(L, -1);
        if (msg)
          luaL_traceback(L, L, msg, 1);

after the `lua_pushliteral` call in `msghandler`. (I'd prefer it that `msghandler` leaves all to-string conversions to the `report` function, though.)

--Andrew

Philipp

Thank you for this. I *mostly* understood that error was the root mechanism that was in use. As long as it's clear that the behavior effects both error and assert and that, imho, both would benefit from more descriptive behavior, I'm happy. :)

Also, many thank you-s for all suggestions. I am motivated to post observations/complaints/etc for the direct comments, but always end up getting far greater value from the general discussion, ideas for work arounds, etc. 

--Andrew

[[ A thought that doesn't belong here, but was inspired by dealing with errors, generally...

When I'm programming, I'm writing a bunch of errors that, through dogged determination, turn into something resembling a useful program that works well enough --- until it errors. During the "get it to work" process, the dialog that I have with the language or the API that I'm using is through interactions with its error reporting facilities / messages, and then its documentation. That is, errors are how I begin to learn.

C#'s "Object not set to an instance of an object" is an example of an error that, while accurate, and perhaps as accurate as it could possibly be, is next to as unhelpful as it might get, if helpful is defined as "what did I do wrong and where do I fix it and is there something that I'm doing wrong generally, which got me here?'

I'm thinking about the concept of "designing errors" or, putting time into the design of how errors help / teach / guide the application developer. In question form: How does one think of errors as an opportunity to help at the time when a developer is most open to help?

This is related to TDD, in that both deal with failure as a touchpoint. But it's different in that TDD is about eradicating error through tests against the API. I'm thinking along the lines of... spotting parts in your API that are tricky and thinking about how the error mechanisms might act as a catalyst to higher understanding...

I'm sure there is an entire CSCI field of study that is already dedicated to this....

]]