Provide error code in addition to text message about rapidjson HOT 3 CLOSED

I like the overall approach taken in the issue23errorcode branch. It's simple and effective.

Somewhat on-topic here as well (because it touches the same code parts), but rather more related to #22, I would prefer to keep a clean way to continue replacing RAPIDJSON_PARSE_ERROR with exception throwing code (as we currently use it locally). This use model is a bit more complicated now and adds unnecessary return paths, which will be dead code in case of exceptions.

We can open a new issue and provide a "standard way" to optionally use exceptions after resolving this issue.

from rapidjson.

Oh, and I should have mentioned that the issue23errorcode branch is affected by #26 as well.

from rapidjson.

I think supporting exception is possible. The dead code ("early return check") can be disabled by preprocessing.
But I don't think exception is really needed. The downside of it is performance overhead and unwinding code overhead.
Can you think of some reasons for supporting it?
If user just want to use try/catch syntax instead of calling GetParseErrorCode(), we can just throw an exception at Parse() function.

from rapidjson.