On Friday, I spent a number of hours trying to run down an error in a fairly substantial piece of code. All I really knew was that I kept getting an error that said something like:
*** glibc detected *** ./my_program: malloc(): memory corruption: 0x0000000002296980 ***
When I pushed this piece of code through gdb, I
A wise quote: When it goes without saying, someone should probably say it.
This is one of the better known patterns out there, but it still bears repeating.
The boundaries for integers
When you're working with a range of integers (for example, human age range could be between 0 and 135), we have two obvious boundary points
In languages like Java, we have a standardized error-handling paradigm in the try-catch expression. Effectively, this hands all error-handling off to the computer, which monitors all code in the try loop for any and every kind of possible error. While we are able to restrict the range of errors in many cases, the fact
In 99.9% of cases, programmers spend most of their planning and initial coding creating the program that they want. They then spend twice as much time adding error-handling code to the original program, because they forgot that things can (and often do) go wrong.
This is happy path programming, or success oriented code.
I don't know how many hundreds of functions I've dealt with with either a void or boolean return type. While a boolean return type at least tells us whether the function ever completed properly, a void return carries absolutely no meaning. Where's the debugging or error-handling value in that?
Constructor functions take a number of
Stop me if you've heard this one. You've just put together a program, and the logic looks alright, so you start handling error cases. As you go, you drop in dozens of new variables, lay down return values every other line, and throw down hundreds of print statements. Worse still, you might resort to