Don't error() upon access of non-existent fields

[nilnor]

One thing I've that annoyed me in the past, that bit me today as well, is that lgi raises errors upon reads for non-existent fields instead of returning nil. I find this annoying since it's (to me) very different from the standard Lua way of just returning nil. Is there a rationale for doing it this way?

My use case btw is a method that accepts either lgi objects or other objects that can be converted to lgi objects for a special conversion method. Whereas this would be a standard Lua conditional one-liner it now requires pcall.

[pavouk]

Originally, lgi allowed storing arbitrary attributes to any objects (and then when retrieving nonexistent attribute it returned 'nil' instead of error()). However, I was personally bitten during development of demos (mainly lgi port of gtk-demo), where mistyping or guessing wrong the property name caused silent and very hard to find malfunction. Therefore I changed the functionality to current way.

It is very easy to change this back (two lines of code), but I'm not sure. I'd like to hear more opinions from other users about this, if possible.

BTW: in your specific use case; would is_type_of operator be helpful for you? Sth like

    if GObject.Object:is_type_of(some_instance) then
        -- some_instance is lgi GObject.Object descendant instance
    else
        -- some_instance is anything else (even e.g. Lua table or string or nil or whatever)
    end

[nilnor]

I see. I see that as a typical property of Lua though, but I see how it could be helpful for the porting. I personally would still prefer it to blend in with the "standard" Lua way, but as you say it would be nice to hear what others have to say.

And no, doing explicit type checking doesn't really help me. Or rather, it would help getting the job done, but I would prefer just doing

object.to_gobject and object:to_gobject() or object

I'm more annoyed by the fact I have to special case lgi objects since they don't work the way most other Lua objects work.

[RenaKunisaki]

It did always seem strange to me to throw an error instead of just returning nil. It is helpful for debugging, though.

[dodo]

Have you tried turning it off and on again?

How about doing the "standard" lua way and hiding the error messages inside a debug mode?

[ntd]

Returning nil for unexistent fields is the Lua way and, although I personally dislike it, this should be the Lgi way too. Consistency is important, also when this means to be consistently wrong.

[v1993]

This is an old issue, but how about allowing to read any field while throwing error on attempts to change non-existent ones? This seems to follow Lua way while keeping helpful errors.