What's everyone's approach to error checking?

[Bryant_McCracken]

I believe most people fall into one of 3 categories:

1. Error-checking… what’s that?
2. Well… if I HAVE to.
3. Error-check ALL the things!!!

I myself generally fall into the third category. I assume that if there’s even the most remote possibility of divine intervention, someone will find a way to cause an error, so I try to do something of that sort.

The problem with my approach, is that I sometimes finding my function becoming bogged down with conditionals and loops and whatnot for purposes of error-checking and validation… Enough so that it can sometimes interfere with clarity of my function’s purpose.

How about you all?

[GamedevCala]

As a senior business developer I rely on defensive coding and ‘never trust the input / user’ in my day job.
So test driven development (TDD) with Unit Tests and input validation is something you naturally grow into

But: Pre-Optimization is the root of all evil.
I try to protect my pointers and encapsulate methods as good as I can to minimize the error checking.

In the end it depends on your experience. Oh, and the best experience is to break your stuff and learn from it

---

Fail Faster - there is no instant win
Twitter: @GamedevCala - Blog: nerd-time.com - Twitch: GamedevCala

[Dan_Szabo]

Hey Bryant,

I’m very much of the defensive programming type myself. I write a lot of smaller tools at work and I often find a lot of relief in having my own error checking and validation returning useful messages long after i’d written the tool and forgotten what my headspace was in.

I also got into this habit when I started handing over my tools to coworkers who would use them in unexpected ways. Most of the time they would come back saying it’s a bug rather than something I didn’t see a need to implement. I found that anything that gets in the way of a smooth user experience will result in a greater chance of them throwing away the tool.

I also agree with GameDevCala - pre-optimisation is the root of all evil. Cover off anything potentially fatal to the program, write some TODOs, but focus on the functionality first.

I’d say you’re in the right headspace and you’ll certainly learn to be strategic about error handling and TDD the more you do it.