That's not necessarily a bad choice, but it's problematic for the reasons you describe. Still, since JSON is concatenative, you could indeed store all of your objects with a comma at the end and then use:
Then you would get problems as soon as you have line breaks inside strings
Then you are not logging JSON. JSON does not permit that.
Also, JSON objects do not have to be single-line to be valid, so you would in fact be working with some self-defined subset of JSON.
Yes, and? Working in a subset of JSON which forbids newlines as whitespace -- that's still JSON, and it solves your problem elegantly.
Do... do you have multiple logging programs, logging to the same file, and one of them wants to insert newlines? Is this a real problem in your dev stack?
It is a real problem in someone's dev stack. I have already written code to preprocess such log files before feeding chunks into a real JSON parser. It didn't make my life easier.
I'm not against logging as JSON at all, but as pointed out, you have to use a subset that makes parsing the logs easy.
That's not necessarily a bad choice, but it's problematic for the reasons you describe. Still, since JSON is concatenative, you could indeed store all of your objects with a comma at the end and then use:
Then you would get problems as soon as you have line breaks inside stringsThen you are not logging JSON. JSON does not permit that.
Also, JSON objects do not have to be single-line to be valid, so you would in fact be working with some self-defined subset of JSON.
Yes, and? Working in a subset of JSON which forbids newlines as whitespace -- that's still JSON, and it solves your problem elegantly.
Do... do you have multiple logging programs, logging to the same file, and one of them wants to insert newlines? Is this a real problem in your dev stack?