as this topic came up before I want to make this an official discussion which might end up in a decision process.
The main question is, do we want to be lenient or meticulous towards developers. I think currently we are mostly very meticulous and complain (aka throw exceptions or errors) when something is not as expected but we could easily work around it. Being more lenient would mean an eventual easier time/nicer experience (no: I had soooo many errors the first few times I used it) but with the drawback that some problems/misconfigurations might lay dormant (which basically means finding ways to help with debugging / finding out what really happens if you need it).
A live example:
Exception or silently ignore (read comments). Both are totally valid ways to go. In case of ignoring it in theory configuraiton validate should be able to tell you when it’s wrong config and therefore ignored.
I made the case various times about cache configuration and merging with defaults (options that a backend doesn’t accept lead to an error, while in fact we could just ignore them as long as the required options for the backend are correct).
Comments please, afterwards let’s see if we need some voting. As this is a very “basic” decision which could have long lasting impact I would assign it an M maybe?
Note: Obviously it always “depends” and there is no always this or that, but for a general direction that we could maybe note down in the CGLs for example…
If there is a case, where it is clear the developer attempted to do something specific and it’s wrong, go throw an explanatory exception as early as possible. If however it is most likely that he did not intend to do something (as in the case above), don’t distract him with exceptions that he probably doesn’t even understand why they came up at all.
I mean in the above case, it is clear that the secondLevelCache configuration is generally optional. So by accidentially leaving out the configuration key, it should be interpreted like “I don’t care (know) about this feature” and throwing an exception will likely disrupt the developer. OTOH, if the secondLevelCache key was existing, but say a string instead of the expected array, that would be a clear sign that the developer was trying to achieve something in the wrong way, so he needs guidance.
tl;dr Be lenient when it can be assumed the developer didn’t intend interacting with the exception raising feature at all, but be guidingly helpful in the other cases.
Nowadays I generally tend to handle errors meticulously, exactly for the reason that errors otherwise might end up unnoticed and make debugging very difficult. However, my recent work with commands and events made it much clearer for me when and where to throw exceptions.
Generally speaking:
if the user needs to know about an error and possibly can do something about it (retry, choose a solution etc), errors should bubble up to the user (in a friendly way).
If something went wrong but the user won’t notice the impact or really can’t do something about it, the error should only be logged.
If the user (or a malicious person / bot) tried something nasty, the application doesn’t need to react with a friendly error, it should fail promptly and probably log the attempt.
A developer should put extra care into phrasing the error message and providing important context information
Try to fail as early as possible (for example, if configuration is wrong, try to fail on bootup / initialization, not only when the actual setting is needed). Misconfiguration errors in production should be handled gracefully, but logged, but we should try to minimize these situations and fail earlier, so errors are detected before production deployment.
So, just some first thoughts, nothing fully thought through yet …
