The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Some people have to work on air gap networks, where you can not copy anything to the network. It comes configured with a couple of approved things like the operating system, and whatever comes bundled with say Visual Studio 2015, and that's it. Nothing else gets in. With good reason too, e.g. see supply chain poisoning like the recent SolarWinds incident.
I'm pretty trusting.
When someone says they're going to give me JSON I assume they'll give me JSON.
So I'd go for it and worry about validation when the party that should be giving me JSON isn't giving me JSON.
So far that has worked pretty well.
In practice, these kind of things rarely break.
You either get JSON or no JSON at all, but rarely (or even never) a badly formed JSON.
Since JSON is such a well defined construct simple parsers are very easy to write. I have a few. The nub is of course in 'a few'. It really falls into the case usage arena. If you know the data a quick regex parser will do. Regex parsers are fundamentally flawed though, and tend to fail on large data sets containing mixed characters (locale is a pain).
So, well-formedness is largely there already. Two dimensional arrays only require a few lines of code. Multi dimensional arrays just a few more. Large unknown datasets across languages? Use someone else's library and save yourself time.
Or you could do one that's significantly faster but skips well formedness checking during search/skip operations, which can lead to later error reporting or missed errors
As with all input to your program, you validate on reception. All the other code that uses that input after that can then assume valid input and you can choose whatever shortcuts you want to on the assumption of valid input.
Doesn't matter if the input is JSON, XML, key/value pairs from .ini files or tokens, you only validate it once on reception.
A key question is what this parser will be used for.
Is it for a hobby project or a production system?
What would be the benefits of the higher performance? Will it be perceivable for human users? Will it save money by requiring less hardware? How much money?
Is there an impact on the development effort? What is the impact on the resulting code in terms of maintainability?
What would be the cost of choosing one option now and updating to the other option later? (is it a full rewrite? would it be simpler to go from A to B, or from B to A? etc.)
What would be the code of implementing both options and letting the user (well, caller) decide which one to use?
There are many things to factor in this decision. Maybe different developers will give different weights to these considerations, and inexperienced developers will overlook some or all of them, but I believe that for most developers the answer would (and should) be "it depends on the details of the situation".
I take a function-first approach. You won't be able to parse the JSON if it's not well formed, so I would do that check first. If performance is poor, then I'd do a trace to find the bottlenecks and address them if possible. I wouldn't want to spend my time unnecessarily tracking down import errors.
I look at it this way - and keep in mind this is purely hypothetical:
Let's say you're bulk uploading parts of some JSON out of a huge dataset. Almost always that JSON is machine generated because who writes huge JSON by hand? Scanning through it quickly is important. If at some point you get a bad data dump, might it be better to roll back that update and then run a validator over the bad document that one time out 1000 when it fails, rather than paying for that validation every other 999 times?
Case 1, input good, output good - answer faster,
Case 2, input bad, error message, but delayed ( is it clear )
Case 3, input bad, program sticks it's tongue out and dies
Case 4, input bad, quiet wrong result
so, who has to deal with 3, and can 4 happen? ( with malicious input ?)
The weekdays are a bit more chaotic, and coffee may not be had until about a half hour after getting to work
Make coffee at home and bring a travel mug?
All jokes aside, sipping my coffee while reading morning emails helps me settle my mind and prepare for the work day. For me there is a settling effect in sipping coffee, even during an ugly commute. I normally work early hours, so the commute isn't as ugly in the AM as the PM, and the folks in the office at my arrival time are doing the same as me, so there is not usually immediate chaos. [Anyone who arrives to immediate chaos appreciates this.]
However -- these days, going to work consists of getting up, starting a pot of coffee, and then logging in. My commute is 35 steps instead of 34 miles.
I tried to explain them to an IBM systems programmer but for some reason he would not accept the concept. Even though all the code he worked with (assembler) made use of base registers. His main beef was "C is a high level language so it shouldn't need them".
Last Visit: 31-Dec-99 18:00 Last Update: 8-May-21 1:44