What's considered best practice to deal with code ...

# code-coverage

[CLOVIS]

What's considered best practice to deal with code paths that are expected to be impossible, but have an error message just in case they actually happen?

I can't actually write a test to cover that part of the program, since I'm pretty sure it's impossible to reach. I still want to have a proper error message in case I'm wrong, though.

[pajatopmr]

I handle these types of issues by avoiding them like the Plague. I do agonize over being right or wrong. My rationale is generally, if I can easily test it, I do so. If it is truly impossible to test then it is very likely impossible to occur. Since I also insist on 100% code coverage for all my projects, that forces me to either write a test or jettison the unlikely code.

[CLOVIS]

So you would leave the impossible case without an error message? What happens if you were wrong and it wasn't actually impossible?

[pajatopmr]

The program will fail in some way, most likely. If it is an uncaught exception, my apps/libraries will intercept that and gracefully report the error with a message to some support email. There is a HUGE difference between Mission Critical (MC) software and the rest of software. I've done my share of MC software but not since the 80's when I worked on and with Ada. For all other software, perfection is the enemy of the good.

[CLOVIS]

Come on, "adding an error message in an obvious case where data is going to be lost" isn't "perfection is the enemy of good".

[pajatopmr]

Dude, different strokes for different folks, You'll get no argument from me. If you're happy with what you are doing, fine. But please don't go looking for fights. When you've programmed for 57 years and counting, you recognize, as I do, that there are many, many ways to write good code. Your premise was that you don't know if data could get lost. My experience is that if you cannot prove it (by writing a test) then it most likely will not happen and it is good enough to ignore it. Should you learn that the premise is wrong, you fix it then and only then. For MC software, you hedge your bets since you may not get a chance to fix it. Is your app/library MC, as in the Apollo Lunar Lander?

[pajatopmr]

YAGNI is another acronym that addresses your original post. While it literally is "You ain't gonna need it", more precisely, it translates to: "If you cannot prove you'll need it, you ain't gonna need it". That said, I would bet that if you asked 100 engineers your question, 50 would agree with you and 50 would not. So clearly, either choice is fine.