You Don’t Know Why I’ve Called You

An advantage of functions (or methods or subroutines) is boxing up a part of a process so it does not clutter up the code that calls it. Like telling one’s spouse to “take out the trash”, it reduces all an operation’s steps into a single name. The code in a function needs only to perform a single task1 according to all the arguments the caller passed in2 or signalling the caller of an error

As the function does not know who called it or why, it does not have the context to know how to react to errors. It does not know if it should log them (and if so, the logging level), retry an operation, terminate the entire process, or ignore the error. The only thing it can do is notify its caller of the error. The caller might have enough information to know what to do; if it does not, it passes the error to its caller

By acknowledging the limitations of its tiny perspective, a function does not try to force its protocols onto any application that uses it, and so avoids the almost comical hacks and workarounds needed to prevent third-party libraries from swamping error logs with uninteresting entries

In a top-down hierarchy of functions, it encourages decision-making at a specific level, and it makes error logging consistent (because all the logging code tends to be next to each other)

  1. Which might entail calling other functions, to which the same rules apply 

  2. No ignoring inconvenient ones 


Now read this

Technical Debt Is Cholera, not Quicksand

Technical debt (TD) – the compromises we make to get stuff out the door – is more often acknowledged and occasionally quantified. We categorize the inefficiency and difficulty working with it—the “interest” on the debt—as an unfortunate... Continue →