Is it OK or not to use getProperty() from invalid (null) ValueTree?

I see that inside getProperty() there is code:

return object == nullptr ? getNullVarRef() : object->properties[name];

So it seems that object == nullptr secures me before any undefined behaviour. But sometimes (very rarely) I get error when calling getProperty() on invalid ValueTree. It is so rarely that at the moment I can’t debug it (I don’t know how to reproduce it) so I am not sure why that error happens. And I am not sure if I should change my code to first ensure if(myValueTree.isValid()) and then call getProperty()?

in juce::ValueTree empty constructor documentation there is explanation:

… A ValueTree that is created with this constructor can’t actually be used for anything, it’s just a default ‘null’ ValueTree that can be returned to indicate some sort of failure.

But further in explanation of getProperty() there is info like that:

… If no such property has been set, this will return a void variant.

So it looks like it is not problem to call getProperty() on invalid ValueTree and it seems the problem is somewhere else in my code. But before I dig deep inside my code to find unknown issue firstly I want to ask you about any advice.

For any help great thanks in advance.
Best Regards.

It looks like ValueTree::isValid() makes the same what is inside of getProperty().

I mean isValid() return object != nullptr. So checking isValid() before calling getProperty() seems to have no sense. But then is there anybody else which met similar problem? I mean getting “Bad access” error when calling getProperty() on invalid ValueTree?

I have no idea where could be the problem. And as I told it is so rarely that I am not sure how to reproduce it.

Can you share the code you’re running that produces the error, and what the error message is?

Calling getProperty() on a null ValueTree will return a void var, as shown in the code snippet you included. So if you’re getting a bad access then it’s likely something else causing the problem?

You can provide a default argument to the overloaded version of getProperty() which will be returned instead of a void var - have you tried that?

To be honest I am not sure if it’s “bad access” error. I don’t remember what the error is.
Last hour I tried to reproduce the error but with no “success” so at the moment I can’t say clearly what the error says but when I get it again then for sure I will write it here. I am almost sure it was “bad access” but not 100% sure. So let’s wait.

And my code looks like that:
I have object which have ValueTree as private member (it seems reasonable for me in my case) and inside of that object I have method which looks like that:

const var& MyObjectWithValueTree::getProperty(const juce::Identifier& ident)
    return myValueTree.getProperty(ident);

And then in another class I call:

if(static_cast<int>(myObjectWithValueTree.getProperty(ident)) == 0)
    // do something

And the error happens on the line with if statement. But not exactly on that line, but somewhere inside of juce::ValueTree methods.

Of course I will try to use version of getProperty() with default argument. But the error is so rarely that I will be not sure if error dissappeared because of “default argument” version of getProperty() or maybe because it’s just not that rare moment.

Now I think that maybe it is problem because I return const var&. Maybe I should use simply var? Doesn’t make a difference in run time?

Now I think that maybe it is problem because I return const var& . Maybe I should use simply var ? Doesn’t make a difference in run time?

Yeah, returning a reference to a local temporary isn’t going to end well! I thought this would throw a compilation error tbf, but maybe it’s just a warning?

It was red marked message during runtime and as I remember I was not able to continue debugging. So I am pretty sure it was not warning.

By the way thanks for const var& explanation. But are you sure it is local temporary? Please notice that original juce::ValueTree::getProperty() also returns const var&. But in fact the version with default value returns not referenced var. So maybe it makes difference.

It is returning a static dummy variable.

It is the better design to check the variable before using it, or use the getProperty() overload providing a default value.

Oh, sorry! The version of getProperty() that takes a default does return a copy - but the one OP’s using here does indeed return a const var&.