If you have not yet started programming you probably think that programmers’ errors are the ones you see appearing on your computer as everything crashes. Once upon a time there was the Windows blue screen which forced you to switch the computer off and on. Apparently, Chuck Norris managed to make a screenshot of that screen.

The most common mistakes of programmers can’t actually be seen.

There are two types of errors: those you can correct and those you will never find.

Compilation errors

The software, since the programming was born, are full of bugs. At debug time, you find compilation errors first. These belong to the category of those that are immediately and for a simple reason: just try to run the program, the compiler will report error line and crashes. Compilation errors coincide with syntax errors. When you happen to find one, look at the line indicated, but also the one before and the next, and check for:

  • Having put the ; at the end of the previous statement
  • Having indicated all the variables with the $ in PHP
  • Not to have invented function names that don’t exist
  • Not having accidentally pressed on the keyboard leaving stray characters
  • Have closed each open bracket, round, square or clip
  • Having closed every open apex or double apex

If the program is running, there’s a good start. Here begins the journey.

Run-time errors

Insirious, hidden, and sometimes bastards.

They make you spend sleepless nights until you find them. And time flies away like when you have fun. Come to think about it, it’s strange as in debugging runtime errors, time takes flight.

Without making too many subtle distinctions, there will be everything that is not syntax error. In runtime errors there are all inconsistent states of the system, that is, all the unpredicted values of its variables. Unpredicted means that the logic of the program was well thought out but poorly implemented or that you are not considered particular configurations of the problem or even that the system does not have sufficient resources to fulfill the requests of the user.

Runtime errors are not always visible. In case of crashes they of course are. But in case of logical errors that lead the program to return a result other than budgeted, the are not. And in this case you can consider the program as a black box and test all possible input configurations to verify that not only the output is correct, but also all the system state variables at each step.

Have you ever tried repeating the same thing with a computer 10 times and the eleventh crashed? So that’s just the problem of the consistency of the states of a system.

0 0 votes
Article Rating
Inline Feedbacks
View all comments