|Is this a real world problem or just a thought experiment?|
It's a real problem.
|the biggest issue here is that you are passing an array into this function for processing so no matter which solution you choose, an error in one object affects the processing of every other item in the array.|
Well, yeah. You normally don't want your function to run if one of its parameters is undefined due to run time errors.
|Why not make this function into a member of the class so that each instance of 'param' can handle individual issues as they come up?|
Which function? implementation_function()? That doesn't make a lot of sense. How would a parameter implement the function it's passed to? And about the other parameters? Does the function get called once per parameter?
|That way data validation is done in the constructor and errors in execution can be handled on a case by case basis.|
Ah, I see.
Parameters are constructed before the function that will use them is decided. Syntactical checks are of course performed immediately, but that's about it. Ultimately, the function is the only one who knows if something needs to be a string, or a variable, or whatever.
it doesn't need to be like this. A table stating the number, types, and writability of parameters for each function could
be assembled. But some functions are a bitch, really. Like the function that takes any even number of parameters. So eff that.
|Depending on specifics this approach might also open the door for each object to be processed in parallel.|
That would just be silly. Even with thread pools, the latency incurred is far too great. Checking a parameter costs one or two integer comparisons.
Framework: Since this function is part of a programming language (more specifically, part of an engine), no errors should occur during normal operation, only during script debugging. Assets shouldn't suddenly disappear, and a script writer shouldn't intentionally send wrong arguments to a function. So, an error would be a sign that something has gone very wrong -- such as data corruption in a user's machine -- or of logical or syntactical errors in the script. Theoretically, the number of errors as a function over time is bounded.