Fail-fast seems like a right way since it simplifies bug detection. But it's a harm for performance cause of multiple checking the same thing at several levels of the system.Simple example.There is a function that input parameters must be not null. And there is function wrapping it, that also await the same parameters also not null. After some activities function-wrapper passes input parameters into first one. So that the same items checked two times: at the beginning of function wrapper and inside wrapped function.So I would like to know how much widespread this style is. Should I write fail-fast code or check everything just once?
Fail-fast paradigm overheads
programming practices;exceptions;error handling
You're missing a vital point - it's not an either or scenario.You only need to check untrusted parameters. In general, this means the borders of your public interface. If you have a chain of public functions that call other public functions and so on, yes, you'll need to check the input multiple times. You also maybe need to revisit your design to properly abstract and encapsulate things that maybe don't need to be public.Another spot where this occurs is working with components that can fail (like databases or network connections). If a network connection fails, you don't just pass null back up the call stack, you identify it early and throw an exception or otherwise abort. There's no need to check the return value all the way up the stack.