malformed documents should throw an exception or return an error instead of aborting

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Make a document and set it via SetNull()
2. try to write the document with a Writer
3.

What is the expected output? What do you see instead?
I would expect some recovery mechanism; If we encounter such a malformed case, 
we need to gracefully handle the problem (i.e. we cannot crash)

What version of the product are you using? On what operating system?
0.1.  Linux.

Please provide any additional information below.
Some of these asserts are down deep in the code.  The current design is not 
geared toward return codes.  My suggestion would be to throw an exception when 
malformed documents are encountered.

Original issue reported on code.google.com by brian.budge@gmail.com on 22 Feb 2012 at 10:18

• Merged into: #79

[GoogleCodeExporter]

I noted that while snooping around in rapidjson.h that it is possible to 
predefine RAPIDJSON_ASSERT, which does allow for recovery via exception 
handling.  Still it would be nice to have extra information about the failure, 
but this is good for now.

Original comment by brian.budge@gmail.com on 22 Feb 2012 at 10:35

[GoogleCodeExporter]

By default, if error is occurred during parsing, the error status, the error 
message and the byte offset of the JSON stream can be obtained via

bool GenericReader::HasParseError()
const char* GenericReader::GetParseError()
size_t GenericReader::GetErrorOffset()

and

bool GenericDocument::HasParseError() const { return parseError_ != 0; }
const char* GenericDocument::GetParseError() const { return parseError_; }
size_t GenericDocument::GetErrorOffset() const { return errorOffset_; }

Please check if they may help. Suggestion are welcome.

Original comment by milo...@gmail.com on 28 Feb 2012 at 6:12

[GoogleCodeExporter]

Yes, that's great for parsing, but I encountered this assert during file 
writing after manually building a document that has null as the root value.  
What might be nice is to augment RAPIDJSON_ASSERT with an informational string, 
something like:

#define RAPIDJSON_ASSERT(A, B)

where A is the boolean to be checked, and B could be a const char * that gives 
information about what it means when A fails.

Then, when someone predefines RAPIDJSON_ASSERT for their own app, they could 
throw an exception where the what() could return that const char *.  This is 
only a suggestion; I'm not sure what is the best way to handle more general 
information about assert failures.

Original comment by brian.budge@gmail.com on 28 Feb 2012 at 2:32

[GoogleCodeExporter]

Yes, I'm using rapidjson to validate and convert the ungodly mess that is 
twitter, into protobuf. Since twitter is not well  documented, and they alter 
the schema from day to day I need to reverse engineer it.

I want an exception thrown when a field is absent or when a field does not have 
the correct type. I could use the IsType and HasMember functions but that is 
just too much code. 

As brian.budge mentioned above. Explicit documentation that is flagged up 
should be provided. Perhaps in the feature list on the front page, since there 
is no documentation at the moment, or perhaps as an example.

Original comment by h.a.s...@gmail.com on 4 Apr 2012 at 1:12

[GoogleCodeExporter]

This is how I am using it at the moment. 

namespace social_sensor
{   
  class rapidjson_exception : public std::runtime_error
  { 
  public:
    rapidjson_exception() : std::runtime_error("json schema invalid") {}
  };
}

#define RAPIDJSON_ASSERT(x)                         \
  if(x);                                            \
  else throw social_sensor::rapidjson_exception();  

#include <rapidjson/document.h>
#include <rapidjson/prettywriter.h>
#include <rapidjson/filewritestream.h>

Original comment by h.a.s...@gmail.com on 4 Apr 2012 at 1:34

[GoogleCodeExporter]

Original comment by milo...@gmail.com on 14 Nov 2012 at 3:40

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I converted my JSON parsing code from boost property tree to rapidjson, 
improving speed and correctness (ptree does not even preserve data types, 
terribly wrong path to go down, sadly).  I had already included exception 
handling of all malformed JSON during extraction while using ptree.  Using 
Hassan's approach in comment #5 worked without any need for additional code 
changes.  Don't forget your try() blocks though!  :-)

Better docs, and rapidjson will easily take over the world!  :-)

Original comment by moodb...@gmail.com on 22 Nov 2013 at 1:06

[GoogleCodeExporter]

Original comment by milo...@gmail.com on 24 Jun 2014 at 2:05

• Changed state: Duplicate