Uninformative error message

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Uninformative error message

Dirk Laurie-2
I have a program with many instances of

    error(msg)

where msg is each time some expression.
If this expression evaluates to a non-string,
the error message is merely

    lua: (error object is not a string)

There are obviously plenty of easy workarounds,
but is there some deep reason why the traceback
is omitted?

Reply | Threaded
Open this post in threaded view
|

Re: Uninformative error message

Daurnimator
On 17 October 2014 12:46, Dirk Laurie <[hidden email]> wrote:
I have a program with many instances of

    error(msg)

where msg is each time some expression.
If this expression evaluates to a non-string,
the error message is merely

    lua: (error object is not a string)

There are obviously plenty of easy workarounds,
but is there some deep reason why the traceback
is omitted?


Calling `tostring()` on errors was added/fixed in lua 5.2.
However, tracebacks are not added.

    $ lua5.1 -e'function foo() error(setmetatable({},{__tostring=function() return"foo" end})) end; foo()'
    lua5.1: (error object is not a string)

    $ lua5.2 -e'function foo() error(setmetatable({},{__tostring=function() return"foo" end})) end; foo()'
    lua5.2: foo
Reply | Threaded
Open this post in threaded view
|

Re: Uninformative error message

Roberto Ierusalimschy
In reply to this post by Dirk Laurie-2
> I have a program with many instances of
>
>     error(msg)
>
> where msg is each time some expression.
> If this expression evaluates to a non-string,
> the error message is merely
>
>     lua: (error object is not a string)
>
> There are obviously plenty of easy workarounds,
> but is there some deep reason why the traceback
> is omitted?

The traceback is not added to the final message (when it is being
printed), but to the error object itself (among other reasons because
the traceback is created before the error is actually raised, while the
stack is still alive). When the error object is not a string, it seems
tricky to append a traceback into it.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Uninformative error message

Andrew Starks


On Fri, Oct 17, 2014 at 2:13 PM, Roberto Ierusalimschy <[hidden email]> wrote:
> I have a program with many instances of
>
>     error(msg)
>
> where msg is each time some expression.
> If this expression evaluates to a non-string,
> the error message is merely
>
>     lua: (error object is not a string)
>
> There are obviously plenty of easy workarounds,
> but is there some deep reason why the traceback
> is omitted?

The traceback is not added to the final message (when it is being
printed), but to the error object itself (among other reasons because
the traceback is created before the error is actually raised, while the
stack is still alive). When the error object is not a string, it seems
tricky to append a traceback into it.

-- Roberto


I wanted to add my .02.

I have a similar setup to what Dirk described. In a few cases I had done something wrong, only to have this message appeared. It has quickly become my most dreaded message.

When it happens, I then pepper my code with print statements, in order to track down where it happened within my project.

I don't have a suggestion that would be especially illuminating, but it is frustrating when it happens and due to the nature of errors and the way that I develop software, it's lead me to wrap `error` so that I can trap this case.

-Andrew
Reply | Threaded
Open this post in threaded view
|

Re: Uninformative error message

Dirk Laurie-2
In reply to this post by Roberto Ierusalimschy
2014-10-17 21:13 GMT+02:00 Roberto Ierusalimschy <[hidden email]>:

>> I have a program with many instances of
>>
>>     error(msg)
>>
>> where msg is each time some expression.
>> If this expression evaluates to a non-string,
>> the error message is merely
>>
>>     lua: (error object is not a string)
>>
>> There are obviously plenty of easy workarounds,
>> but is there some deep reason why the traceback
>> is omitted?
>
> The traceback is not added to the final message (when it is being
> printed), but to the error object itself (among other reasons because
> the traceback is created before the error is actually raised, while the
> stack is still alive). When the error object is not a string, it seems
> tricky to append a traceback into it.

Maybe 'nil' could be treated differently from other nonstrings,
and error() be allowed.

Reply | Threaded
Open this post in threaded view
|

Re: Uninformative error message

Roberto Ierusalimschy
> Maybe 'nil' could be treated differently from other nonstrings,
> and error() be allowed.

We could make an error to call 'error' with nil...

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Uninformative error message

Jay Carlson

On Oct 19, 2014 8:55 AM, "Roberto Ierusalimschy" <[hidden email]> wrote:
>
> > Maybe 'nil' could be treated differently from other nonstrings,
> > and error() be allowed.
>
> We could make an error to call 'error' with nil...

I like that. But I am a hardcore errorist, so of course I would like that.

Reply | Threaded
Open this post in threaded view
|

Re: Uninformative error message

Andrew Starks


On Sunday, October 19, 2014, Jay Carlson <[hidden email]> wrote:

On Oct 19, 2014 8:55 AM, "Roberto Ierusalimschy" <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;roberto@inf.puc-rio.br&#39;);" target="_blank">roberto@...> wrote:
>
> > Maybe 'nil' could be treated differently from other nonstrings,
> > and error() be allowed.
>
> We could make an error to call 'error' with nil...

I like that. But I am a hardcore errorist, so of course I would like that.


Yes. I'd do anything for a stack trace there. 

I've got Mega Bug, right now. I can't figure out how, but I've managed to create a situation where an error generated inside of a pcall is not returning to the pcall and instead of showing the error message, it gives this error, with no line number, file name, etc. I'm guessing it's some Frankenhack side-effect but I've been at it for a few hours and wrapping error doesn't have any effect. 
Reply | Threaded
Open this post in threaded view
|

Re: Uninformative error message

Dirk Laurie-2
2014-10-20 1:55 GMT+02:00 Andrew Starks <[hidden email]>:

> I've got Mega Bug, right now. I can't figure out how, but I've managed to
> create a situation where an error generated inside of a pcall is not
> returning to the pcall and instead of showing the error message, it gives
> this error, with no line number, file name, etc. I'm guessing it's some
> Frankenhack side-effect but I've been at it for a few hours and wrapping
> error doesn't have any effect.

You could always invest a few minutes in making an appropriate change
to the following code in lbaselib.c and rebuilding. Just this once, mind. :-)

  if (lua_isstring(L, 1) && level > 0) {  /* add extra information? */
    luaL_where(L, level);
    lua_pushvalue(L, 1);
    lua_concat(L, 2);
  }