Support nlohmann::basic_json::value with JSON_NOEXCEPTION

[ingomueller-net]

Currently, accessing an objects element through value (to get a default value if not present) does not work if compiled with JSON_NOEXCEPTION. This is because it is implemented similar to:

try {
    return at(key);
} catch(out_of_range) {
    return default_value;
}

If exceptions are disabled, this terminates the program even though it is obvious what the user wanted, namely the provided default value. Why is this not implemented similar to this:

auto const it = find(key);
if (it != end()) return *it;
return default_value;

As far as I can see, this has the described semantics (except that the description currently says that it is based on exceptions) and the same complexity, but works with JSON_NOEXCEPTION.

[nlohmann]

The code with at and try is only to describe the behavior. The actual implementation is this:

template<class ValueType, typename std::enable_if<
             std::is_convertible<basic_json_t, ValueType>::value, int>::type = 0>
ValueType value(const typename object_t::key_type& key, const ValueType& default_value) const
{
    // at only works for objects
    if (JSON_HEDLEY_LIKELY(is_object()))
    {
        // if key is found, return value and given default value otherwise
        const auto it = find(key);
        if (it != end())
        {
            return *it;
        }

        return default_value;
    }

    JSON_THROW(type_error::create(306, "cannot use value() with " + std::string(type_name())));
}

An exception is only thrown in case the value is not an object. Would that work for you?

[ingomueller-net]

Sorry, I didn't specify that I was referring to the json_pointer overload.

[nlohmann]

We could realize this via the contains function which only throws in case of invalid JSON pointers. I am not aware of a find overload for JSON pointers.

[ingomueller-net]

This would solve my problem. I had thought of find to avoid two lookups (one for contains, one for at), but I haven't done much digging...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.