Failing to extract value from JSON why?

[KroMignon]

@SPlatten said in Failing to extract value from JSON why?:

if it couldn't then I would expect an error.

Qt is avoiding exception usage, so what kind of error did you expect?
And you should not expect to much but simply some time hit the F1 key on your keyboard to get the help for the function. All is documentation, you only have to read it.

[SPlatten]

@JonB normally I always check the return of a function, I will revisit this code.

[SPlatten]

@KroMignon , Why is Qt avoid exception usage, if there is an error then there should be a mechanism for finding out what was wrong.

[JonB]

@SPlatten
The answer is to this is historical/per language. C, and then C++, used function return results to indicate errors, not exceptions. (Exceptions are regarded as "expensive" in C++, but that's only one reason.) It's not always true now --- some C++ libraries do use exceptions --- but plenty stick with that approach. Qt is just following that pattern, which is not unreasonable for C++. Some other languages, e.g. C# or Python, tend to raise exceptions, as you prefer. That's just how it is.

[KroMignon]

@SPlatten said in Failing to extract value from JSON why?:

Why is Qt avoid exception usage

Again, this is documented ;)
https://wiki.qt.io/Coding_Conventions
https://doc.qt.io/qt-5/exceptionsafety.html

[JKSH]

@SPlatten said in Failing to extract value from JSON why?:

normally I always check the return of a function, I will revisit this code.

Good. So check if toString() returns a null string -- that's your error, as @JonB said.

the name of the function is toString, so I expect the result to be whatever is on the left converted to a string.

Following that logic, would you also always expect QJsonValue::toArray() to convert your value to an array, and QJsonValue::toObject() > to convert your value to an object, and QJsonValue::toInt() to convert your value to an integer? Even if the value is not an array or an object or a number?

@JKSH , of course, and if it couldn't then I would expect an error.

{
    "a": "TruE",
    "b": true
}

Suppose robjRequest contains the above. Tell us what each of these should return:

1. robjRequest["a"].toArray()
2. robjRequest["a"].toObject()
3. robjRequest["a"].toString()
4. robjRequest["a"].toInt()
5. robjRequest["a"].toBool()
6. robjRequest["b"].toArray()
7. robjRequest["b"].toObject()
8. robjRequest["b"].toString()
9. robjRequest["b"].toInt()
10. robjRequest["b"].toBool()

[SPlatten]

@JKSH , this is just silly, the name of the function is toSomething, so the name implies that it will convert whatever to the 'something', at least that is exactly how I would code it and expect it to work.

[JKSH]

@SPlatten said in Failing to extract value from JSON why?:

@JKSH , this is just silly, the name of the function is toSomething, so the name implies that it will convert whatever to the 'something', at least that is exactly how I would code it and expect it to work.

I don't understand how you expect toArray() to work on "TruE" or true.

Consistency in an API is important. QJsonValue::toArray() only works on 'something' when that something is an array. Likewise, QJsonValue::toString() only works on 'something' when that something is a string.

[SPlatten]

@JKSH , thanks, I really can't be bothered to debate this any further.

[kshegunov]

@SPlatten said in Failing to extract value from JSON why?:

@JKSH , this is just silly, the name of the function is toSomething, so the name implies that it will convert whatever to the 'something', at least that is exactly how I would code it and expect it to work.

No, it isn't that silly, actually it's very much on point.

An API, which is what Qt provides, is a contract (the technical idiom is "Design by contract") - you give us this, and we give you that in exchange. You broke the contract, and you didn't bother to read the contract, and that's all fine with me, but to add insult to injury - you're claiming it's not worth reading the contract. Sorry, that ain't gonna fly!

If you're not up to speed on what I'm babbling about, well the documentation is that contract, if a function name was all and enough we wouldn't bother to write documentation at all.