Separate error offset from error message#70
Separate error offset from error message#70finitemonkey wants to merge 1 commit intotreeform:masterfrom
Conversation
|
Adding offset is responsible but removing it from the error message is bad, not everyone will have a pretty printer. |
|
Yeah, I agree and I almost left the offset in the error message for this PR. Of course, we could just put it back with the only downside of a tiny amount of redundant info. However, there is another option - what if I improved the pretty-print proc so that it was suitable to include with JSONy? In the comment above, the proc is just a good-enough-for-my-purposes hack, but what if it;
Then perhaps in the case that we are in a debug build the pretty-print version can be used (without offset tagged onto the end of the error), but in a release build the standard short (and faster to generate) message is used (with offset at the end of the error message)? |
|
My fear is that JSON i deal with is in GBs. I don't want to print full json as it would scroll forever. There is probably a way to have a nice json error though. Some thing that prints only few lines before and after, but if there isn't any lines it prints bytes instead. |
|
I would be in favor of including the offset in the error. I'm also typically dealing with large JSON that's compact (no newlines), so I would want my pretty printer to look something more like: Sure, it's definitely pretty blunt, but from a debug standpoint it's typically all I need. Having the offset in the error would be especially nice so I won't have to parse it out of the message 😄 |
Hi! Thank you for all your work on this library, it is working well for me but I had a problem with exception error messages not giving enough insight.
The person who raised issue #26 wanted the errors to convey more detail about the nature of the error, but in my case I really just needed to get a better idea of where we are in the JSON as I was having difficulty quickly translating "At offset: 357" into something meaningful.
You said in #26 that although better messages would be nice, you do not want to keep any additional state as it would slow down parsing (fair enough)... so the idea of this PR is that if the offset value is separated from the message part of the error, into its own var, it would allow a proc to be written to reconstruct the offset info into a more human-friendly form. A proc something like this;
Example usage;
resulting in an error message like this one;
Ah, much better! And without any impact on jsony's parse speed. What do you think? Am I overlooking anything important?