Error checking question

Started by
2 comments, last by vreality 12 years, 3 months ago
I notice alot of programs don't check EVERY single return value for their use of win32 functions. Is thos considered bad programming practice? in my code should i check any function that has a chance to fail? Will this drastically slow down my code if i do so putting so many checks within it?
Advertisement
It's generally good practice to check the return value of functions that return exit codes and respond to failed functions by trying a different method or displaying an appropriate error message. If you don't spend the time to do that now, you may have to spend a much larger amount of time later locating bugs caused by your API calls. A dialog box concisely describing an error is more helpful and looks much more professional than having the program halt with a obscure memory allocation error that happens nowhere near the offending code.
As a side note, you usually want to have your os functions calls hidden behind a nice interface. One benefit of this is that you can have your lower level functions check the return value of win32 function then thrown exceptions if they can't fix the problem so that higher level function can handle them in the appropriate manner to avoid muddling the overall logic of your program.

I notice alot of programs don't check EVERY single return value for their use of win32 functions. Is thos considered bad programming practice?
[/quote]
Yes.


in my code should i check any function that has a chance to fail?
[/quote]
You should check any function that has documented ways of signalling failure, regardless of how unlikely you think it is that they might fail.


Will this drastically slow down my code if i do so putting so many checks within it?
[/quote]
You generally don't make calls to Win32 often enough to worry about this. Even if you did, consider an alternative question: will crashing as quickly as possible, in the name of performance, help or hinder your product?

Omitting error checking and handling is the definition of premature optimisation. Your bottleneck will be somewhere else, I guarantee it.

Even if you don't have a meaningful response or solution to unexpected return values, it's a very good idea to simply report any unexpected result and bail. For instance you could "assert" expected return values during development.

That way, if you ever start getting unexpected results from those API calls, you will know about it immediately, and will have already worked yourself into conditions which cause them, putting you in the best position to then implement an appropriate response (as well as providing an opportunity to find a way to avoid those conditions to begin with).

The general idea is to use immediate failure feedback to lead you to a usage pattern that never produces the undesired results.

But if your published program ever does receive unexpected results from a core API, it has most likely failed and can't proceed as intended. If you don't check for this, it'll most likely lead to a crash. If you do, you can at least shut down cleanly, and might even be able to drop the user a hint as to what conditions are preventing the program from working.

This topic is closed to new replies.

Advertisement