I was working with a developer at a decently sized startup that was writing some core classes that most of the other developers would have to call to make the website function.

There was a function, let's call it getValue, that took in a single value for the key.

When I was doing a code review I could see that if you failed to pass in a key it would just return a default empty value. If for some reason there was any error, such as not being able to connect to the data source, then it would just respond with the same empty value.

This means that any actual errors would be hidden from the many developers that will use this code. This could confuse and even allow bugs to propagate to production because the developers would never see the errors that their code was creating when calling this class. In fact, if a developer running this code forgot to boot up the data source locally or connect to it remotely they would never know. They would just get that empty response.

One objection that came up was "What if there were a problem connecting to the data source on production? We wouldn't want it to error out then". On the contrary, if for some reason it is not operating as designed then I would want to know about it and fix it ASAP instead of sweeping the error under the rug.

Moral of the story: When designing tools that other developers will use it's fair to add bumper rails but do not hide important information that could cause them to push out bugs. Throw an error so they can find and fix the problem.