Let me stress your point to the parent: > letting the compiler figure out which one to call when and obviating the runtime exception entirely. That is how FP

Let me stress your point to the parent: > letting the compiler figure out which one to call when and obviating the runtime exception entirely. That is how FP eliminates a whole category of bugs. You have to have "experience", which some love to boast, to know that it's better to have an else clause there and throw an exception. If you think that's basic knowledge you'd be surprised with how little do "experienced" programmers that get paid very handsomely actually know; I've met 30-year of experience programmers that do not believe that the final-else-then-exception pattern is a good idea, because they think "crashing the program is never good". So what ends up happening is of course the program ends up crashing anyway (supposing you have passed an invalid connection in that case) but now the stack trace is potentially much deeper than it needs to be, and therefore misleading. All stack traces lose their value collectively because now we can't tell the good ones from the bad. That can make debugging harder than it needs to be. But instead in FP, because it's a fundamentally different way to program, that situation doesn't even arise in the first place, obviating a solution. In FP things are modeled differently from OO, it's not just "procedures without an object jacket". The advantage here is the compiler verifies the "object" selection for you (which "class"/type of connection) and can provide some mathematical guarantees. Those guarantees are what metonymically "eliminate bugs". So we can rely less on the programmer and more on the compiler. You know, like it's meant to be. After all we are sitting in front of a computer, so we should just let it do its thing without telling it how. Turns out autonomy in coming up with a solution is good both for the programmer and for the computer (and then again for the programmer).