Learning to Program- Two Main Types of Errors 2

This entry is part 20 of 22 in the series Learning to Program

In programming, you’ll encounter a lot of different errors. Syntax errors, functional errors, configuration errors, and more. All of the errors can be classified as two main types though: compiler (or compilation) errors and run-time errors.

Compilation errors are the syntax errors and other problems encountered while creating the program. They are found and fixed before the program is released to the customer (end-user or the public, as the case may be). These won’t impact the customer, because you’ll fix them before you release. Otherwise, your program won’t work.

Run-time errors are errors that involve the logic or function of the program. Some of them will happen before release, and some will happen after. The goal is to make sure most of them happen before release, but nothing is perfect.

One example of a run-time error is in a program that I’ve been developing. Essentially the program is an updater for an IP Address. The error is that once I enable “Automatic updating”, I can’t disable it (or change the time-frame for the updates). It’s a functional error, because while the logic is sound (making sure you can automatically update and set the interval), the way it’s implemented doesn’t work.

If you have run-time errors after the program is released, you’ll be informed via bugs or security notifications (depending on the type of error). Some of the errors are features that don’t work properly, features that people want, security vulnerabilities, or other problems.

The point here is two-fold. First and foremost, you’re going to run into compilation errors and run-time errors. If you don’t, then the program was either fairly simple, or you didn’t write it. Now, let me clarify that occasionally you’ll write a complex program without any errors–but it’s rare.

Secondly, your goal is to minimize all of the errors as much as possible. Your goal is 100% perfect code. Your reality should be somewhere between 92% and 98% perfect code. Don’t release unless your compilation errors are 2% or lower, and your run-time errors are 5% or lower.

And test for every possible scenario that you can think of. Even the ones that are highly improbable. Because, the more people who use the program, the more probable one of those scenarios will happen. And have others test for everything they can think of also. That’s how the “professionals” do it.

Have a great day:)

Series Navigation<< Learning to Program—Random Thoughts with a ThemeLearning to Program – Integrated Development Environments (IDE’s) >>

Leave a Reply to Steve Lockwood Cancel reply

Your email address will not be published. Required fields are marked *

2 thoughts on “Learning to Program- Two Main Types of Errors

  • Steve Lockwood

    Is there a specific way to program things that will automatically save certain types of entries in case of data loss due to something breaking? That seems kind of vague, but my friend just broke his iPad and was wondering about that. He is thinking about calling a Calgary computer service to fix his iPad but in the meantime we’ve been talking about that.

    • patscomputerservices

      Most applications (like word-processing and spreadsheet applications) have an “auto save” feature. You may have to check in the preferences to make sure it’s enabled (and set the time), but in a lot of cases it happens automatically. So, in theory your friend should be able to open the apps and have a “Recover your work” box come up.

      Of course this depends on the developer and the platform. The big name developers (Microsoft, LibreOffice/OpenOffice, etc) will have that feature built in. Smaller developers may not take the time to code it in. If you’re a coder, you can read through the code for LibreOffice or OpenOffice, and find out how they implement the function–then add it to your programs.

      Have a great day:)