crapy interface

[microcai]

access non-exist node leads to ASSERT.

no auto type convert, just throws.

you have to write LOTS OF try /catch block, just to get a value
that is stupid, that's not morden c++. it is just stupid JAVA style.

YOU USE EXCEPTIONS WRONG. stupid.

[theodelrieu]

You use english wrong, my good sir.

I don't get your problem though, care to join an example?

[TurpentineDistillery]

@theodelrieu, I don't think it would be prudent to invite a discussion here. I'm sure the OP can find a different json lib more to their liking.

[pboettch]

OP has a problem with non-existing fields in his JSON. So, he obviously is missing some kind of validator for his code. Luckily for him there is at least two of them working with this library: ValiJSON and Modern C++ JSON schema validator

[markand]

YOU USE EXCEPTIONS WRONG. stupid.

Sure you will teach us how to use it better. I think you're better using another JSON library because we are absolutely fine.

[nlohmann]

@microcai, it saddens me to hear that my library did not uphold its reputation to bring JSON to Modern C++. While an intuitive, STL-like interface is the focus of the project, you describe two issues where it apparently fell short:

Auto-conversion

It is a frequently expressed requirement to automatically convert between the different JSON types (boolean, string, number, etc.). Unfortunately, only between some of these types a meaningful conversion exists. Off the reel, number-to-boolean conversion would come to mind. However, an object-to-number conversion makes no sense.

To this end, this library decided to use exceptions to signal situations when a conversion cannot be made. The exception string then describes the problem. We decided against a C-like interface where an additional return value indicates whether the conversion succeeded. Unfortunately, we are not aware of a way to have the compiler enforce type correctness.

The good news is that there are several idioms to avoid coping with exceptions. First, there exist several member functions to determine a JSON value's type. For instance, is_boolean() can be called prior to a conversion. There also exist a member function type() to query an enum value to write a switch statement with a case for each type.

Second, one can query a pointer to the actual value via get_ptr. This function returns a null pointer in case the requested type is not compatible. This basically simulates the aforementioned C-style API and instead of dealing with exceptions, you only need to check the returned pointer prior to dereferencing it to the actual value.

From your error report, I understand your dislike of Java for its frequent -- occasionally excessive -- use of try/catch blocks. You may rest assured that you do not need to spoil your code with such patterns. In fact, you can compile the library with -fno-exceptions when you also define the macro JSON_NOEXCEPTION.

Access to non-existing elements

In the library's pursuit of mimicking the STL where possible, we decided to offer an operator[] for both objects and arrays to implement unchecked access.

The semantics of these operators differ when applied to const or non-const values. In case of non-const (i.e., mutable) values, accessing a non-existing key performs an insert of a null value at this key before returning a reference to it. (This is basically nothing new for friends of std::map.) Apparently, we cannot follow this pattern for const values. There have been lively discussions how to resolve this dilemma: not offering the operator for const values or to use a debug assertion to ensure the passed key is always present.

Despite the STL's choice for the former approach, the library chose the latter. We are well aware of the ramifications as we chose convenience for some over the confusion of others. As justification (or in your case, rather an excuse as you apparently were surprised by our audacity in this regard), let me add that we still also offer at for range-checked access (notwithstanding its, as you may call it, Java-like exceptions), but also a find method for keys which returns a past-the-end iterator in case the key was not found.

Of course, protecting a precondition with an assertion may feel extreme. However, it helped to surface your confusion during development time and did not jeopardize a production environment where assertions would have been switched off.

Once again, let me offer my apologies. Please feel free to engage the discussion with us about the design choices. We are always happy to improve the documentation of our endeavor to bring JSON to Modern C++.

[nlohmann]

It's a pity not to hear back from @microcai.