JSON errors

[petehug]

I'm a little puzzled that wjelement seemingly misses a very fundamental feature, namely handling erroneous JSON streams.

WJEOpenDocument seems to swallow anything it doesn't recognise. So if I parse this non JSON string "{this 1 is truely not working}" it returns an empty object. I tried to use the callback I can provide to WJEOpenDocument, but in this example it is only called once with all parameters NULL.

Is there any way of handling errors?

[penduin]

The library's original purpose was for a webserver, so its design philosophy is to be as forgiving as possible with data coming in and as correct as possible when spitting it out. Validation is something we've thought about afterwards, but we don't have any specific plans for it yet.

WJReader could certainly gain some new logic for complaining about errors as it parses a document; that's probably where I'd start. If you've got some specific ideas or requirements in mind, this is the place to discuss it! :^)

[petehug]

One way of providing this feature would be to add a function WJEStrictOpenDocument which would behave generally like WJEOpenDocument but would offer these extra bits:

• user MUST supply an error buffer and an error buffer length parameter (recommend a length)
• the function fills the error buffer with a message and returns NULL if it discovers a JSON syntax error

Check out http://jsonlint.com/, it simply reports the first problem it finds in the stream and stops. A message like that would be satisfactory.

[minego]

My plan is to add an error callback. Each time an error is warning is encountered it will be called with the position in the document, the severity of the error and a text description of the error.The callback's return value would be used to indicated if the parser should attempt to continue or should give up.Micah-- Sent from my HP VeerOn Apr 15, 2014 8:32 PM, Pete Hug [email protected] wrote: One way of providing this feature would be to add a function WJEStrictOpenDocument which would behave generally like WJEOpenDocument but would offer these extra bits:

user MUST supply an error buffer and an error buffer length parameter (recommend a length)
the function fills the error buffer with a message and returns NULL if it discovers a JSON syntax error
Check out http://jsonlint.com/, it simply reports the first problem it finds in the stream and stops. A message like that would be satisfactory.

—Reply to this email directly or view it on GitHub.

[petehug]

My bottom line is: I want to call WJEOpenDocument and if it returns NULL, I want access to error details.

You could write an OJROpenDocumentStrict function which provides a strict error handler callback which, when called, stores error details in the reader and request to stop processing. The OJROpenDocument function provides no handler so everything works as it does now which would be great for backwards compatibility. It would also mean that only in the rarest of cases would one have to implement his/her own error handler callback.

[minego]

A strict interface could easily be done using the callback approach. I like that idea and will plan to include that.That gives a very easy interface either for strict or forgiving parsing, and allows more advanced usage with the callback.-- Sent from my HP VeerOn Apr 15, 2014 11:05 PM, Pete Hug [email protected] wrote: My bottom line is: I want to call WJEOpenDocument and if it returns NULL, I want access to error details.

You could write an OJROpenDocumentStrict function which provides a strict error handler callback which, when called, stores error details in the reader and request to stop processing. The OJROpenDocument function provides no handler so everything works as it does now which would be great for backwards compatibility. It would also mean that only in the rarest of cases would one have to implement his/her own error handler callback.

—Reply to this email directly or view it on GitHub.

[primohan01]

while using valgrind for memory leak purpose , I am getting memory leak in below mail.
it seems to be WJROpenFILEDocument function initialize the value as well as does the memory allocation. Now if it is successful then memory deallocation needs to be done .
if((readschema = WJROpenFILEDocument(schemafile, NULL, 0)

Note: WJElement schema_load function calls above function and inside this function memory load is happening.

Please let me know your though on this.

[penduin]

Good catch. I'll dig in and see whether WJECloseDocument is neglecting to free something, or maybe isn't even getting caled at all in this case.

Thanks for the tip, I'll post my findings and a fix as soon as I can. :^)

-Owen

-- Sent from my HP TouchPadOn Nov 20, 2014 7:24 AM, primohan01 [email protected] wrote:

while using valgrind for memory leak purpose , I am getting memory leak in below mail.

it seems to be WJROpenFILEDocument function initialize the value as well as does the memory allocation. Now if it is successful then memory deallocation needs to be done .

if((readschema = WJROpenFILEDocument(schemafile, NULL, 0)

Note: WJElement schema_load function calls above function and inside this function memory load is happening.

Please let me know your though on this.

—
Reply to this email directly or view it on GitHub.

[penduin]

@primohan01 I just put in two changes:

• the validate.c example now passes a free callback
• WJESchemaValidate will deal with a NULL freecb better (by using WJECloseDocument itself)

It's easy to imagine a situation where the consumer needs to use something (in void *client) to clean up properly, so putting that in the example was good. WJESchemaValidate now follows the common WJElement convention where if there is no free callback and it's time for a document to go away, we just close it. That way, consumers who don't need to do anything fancy don't need to bother providing the callback.

Now, off to update the documentation. :^)

[penduin]

I'm leaving this issue open, because although I fixed this leak, the original request for some kind of JSON (format) validation remains valid. We probably should have split this out into its own issue... Oh well.

[minego]

I am working on providing an error handling mechanism.
On Apr 15, 2014 7:17 PM, "Pete Hug" [email protected] wrote:

I'm a little puzzled that wjelement seemingly misses a very fundamental
feature, namely handling erroneous JSON streams.

WJEOpenDocument seems to swallow anything it doesn't recognise. So if I
parse this non JSON string "{this 1 is truely not working}" it returns an
empty object. I tried to use the callback I can provide to WJEOpenDocument,
but in this example it is only called once with all parameters NULL.

Is there any way of handling errors?

—
Reply to this email directly or view it on GitHub
#28.

[valentino-fiorin]

Hi @minego, @penduin,
Have you made any progress on this enhancement?

Thanks