Hi Wendy, Interesting suggestion. I assume that the fields will be optional, right? A consideration is that the syntax errors typically are caught by a JSON parser. I know that you know quite a few parsers. Will the existing parsers give such information (e.g., line, character)?
To others: if you have used multiple parsers, your experience can be quite helpful here. Thanks! Richard On Thu, Oct 10, 2013 at 12:50 PM, Wendy Roome <[email protected]>wrote: > As current;y defined, E_SYNTAX gives no indication as to where the error > is or what was wrong. So how about adding the following additional fields > for E_SYNTAX: > > "line" Optional line number (first line is 1) > "character" Optional character in line (first character is 1) > "reason" Optional error message, which may or may not include line and > character. > > This raises the question of what language to use for "reason". At the risk > of coming across as an English chauvinist, I suggest that it be in > English. After all, the RFC is in English, and the field names are > English. So it's pretty unlikely that server and client programmers won't > understand enough English to deal with a simple error message. And I don't > see a client library displaying that message to the end user; instead the > lib would log it for analysis by the developers. > > And if a server isn't able to give an English error message, use "line" > and "character". > > - Wendy Roome > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
