You are right, and in this case - in this function, I donât need to check the implementation. This is the most simple example which I posted. In other functions, part of the behaviour required is efficiency. Needlessly calling Enum.map
- for example and recreating data, would be a bug.
Hereâs a contrived example:
input data is a list:
["a", ["b"]]
Expected format is list(list(String.t))
The function will pass through the list unchanged if its conformant. If not, it will fix it and log a warning.
So in this case it will return:
[["a"], ["b"]]
If its passed something like this, however:
[["a"],["b"],["c"]]
then it should just return the list.
A big question in my mind is of course that the cost of checking (which would use Enum.all?
) is probably not much different to using Enum.map
for every list in nay case ???)
This is only a concern to me because I want my functions that work on the lists to be able to assume the list format is as expected, and only check it as it comes in to the system (from 3rd parties who do often get it wrong, and as a service provider, we let them know, but donât want to halt the machinery by being pedantic if we can do a few fixes here and there.
Perhaps the answer is to let the data in unchanged, let it loose on the handlers - who assume the data is conformant - and will raise errors if not⊠wrap the entry with try and then if it fails, log the error and attempt to fix the data and then retryâŠ
I have probably partially answered my own question above (try) but also, just realised I have been amazingly dumb because when it âfixesâ the data, it logs a warning - so all I need to do is to mock Logger.bare_log
and refute called Logger.bare_log
âŠ
However, from a best practices point of view, whats your opinion on using try as suggested above? I am kind of thinking of try as being better to let errors crash the process - because they represent bugs rather than bad input data. I am thinking this way because of the way exceptions mess with lazy codeâŠ