Go Down

Topic: BEGINNERS: COMPILE TIME vs RUN-TIME ERRORS (Read 1 time) previous topic - next topic


For beginners, there is a high _expectation_ the IDE/compiler will tell you what is wrong with your program, and how to fix it...
This is only true a *fraction* of the time.

Interpreted languages may help a bit at runtime, but compiled languages will only show runtime errors if *you* catch them, and display an error message.... rarely on an Arduino sized sketch.

Example: You add numbers beyond the capacity of a variable - and the value overflows... or - an array is too small for your data, and corrupts adjacent storage.  Without your help, the program can't know where, or when these will occur until *after* they have happened.  And the symptom is a crash, or corrupted results without any indication.

COMPILE-TIME ERRORS are slightly better, in the IDE/compiler can let you know when there is a structural or logical problem in your code that the compiler doesn't understand.
These indications are only *indications* where the compiler 'failed' to understand your intentions... it can only make a best guess.

Example: You begin an if(), while() or other construct - without closing the code block { properly... }
The compiler can't read your mind, and only knows the } is missing, not *where* it should. go!  The error will only be indicated at or *somewhere* after where it *should* have been... so the error is announced, but *you* have to look through your sketch to identify whether it's missing or in the wrong place.

Good luck.
When posting - use the toolbar and read the stickies if you're not sure!  </code> tags are our friend!
You can lead a plug to an outlet, but you can't make them turn it on.


If you want maximum help from the compiler in getting your code right, go to Preferences and set the warning level to "ALL".  In some cases you will get warnings that point out things that won't actually cause your sketch to fail but in many cases the warnings are for things you must fix for your sketch to work.

If you have brackets in the wrong place you will probably get one of these errors:

"does not name a type"  or 
"expected declaration before"
Usually means you forgot a '{' or put in an extra '}' in the previous function.  Since all of the open brackets have been closed, the compiler is looking for further global declarations (variables or functions).  If it finds something that looks like executable code instead of a global declaration it emits an error.  Count the brackets in the preceding function declaration.

"a function-definition is not allowed here"
Usually means you forgot a '}' or put in an extra '{' in the previous function.  Since a set of brackets has not been closed yet the compiler is looking for more code to put in the function.  You can't declare a function inside a function so if the compiler finds a function definition it emits an error.  Count the brackets in the preceding function declaration.

"expected '}' at end of input"
Usually means you forgot a '}' or put in an extra '{' in the last function in the sketch.  Since a set of brackets has not been closed yet, the compiler is looking for more code to put in the function.  When it hits the end of the file instead it emits an error. Count the brackets in the last function declaration.
Send Bitcoin tips to: 1G2qoGwMRXx8az71DVP1E81jShxtbSh5Hp


Aug 26, 2017, 07:52 pm Last Edit: Aug 26, 2017, 08:02 pm by Robin2
The other essential thing (IMHO) is to develop your program in small pieces compiling and testing as often as possible. That way the cause of an error will be easier to spot - for example you had a 20 line program working and now the extended 22 line version does not work. So the problem must have been introduced by those 2 additional lines.

Two or three hours spent thinking and reading documentation solves most programming problems.


The compiler does a pretty good job of detecting syntax errors; those errors where the code does not obey the rules of the language. Any beginner should expect their fair share of those. Semantic errors, where the rules are followed, but the context is wrong, like you mentioned the forgetting a set of brackets, are much harder to find. For example, most sentences need a noun and a verb. However, while saying: "The dog meowed." obeys the syntax rules, it gets the semantics wrong. It is very hard for a compiler to catch all semantic errors.

Good coding practices, like Robin2 mentioned, help but experience is going to end up being your best teacher.


No compiler can catch all your errors, for two reasons.

First, a compiler can't telepathically know what you are trying to do. If code looks questionable: hey, maybe you meant to do that. If compilers could "just know" what you meant, then we wouldn't need people to write code at all.

Second, a compiler cannot know what a chunk of code will do when it is run. This is called the "halting problem". A compiler in general cannot compute whether or not a loop will exit (although, of course, in many specific simple cases it can).

Go Up