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.
RUN-TIME ERRORS
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.
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.
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.
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).
string my_value = Console.ReadLine();
int i = my_value;
A string value can't be assigned a variable of type int, so the compiler knows for sure at compile time that this code has a problem
Run time:
string my_value = Console.ReadLine();
int i = int.Parse(my_value);
Here the outcome depends on what string was returned by ReadLine(). Some values can be parsed to an int, others can't. This can only be determined at run time
And lets not forget that some things that you think should generate a warning or error will not because it is valid syntax. Examine the if statement, it is clearly wrong as we are assigning not comparing. But as this is valid, the compiler and run time will be more than happy to execute this code.
int testMe = 12;
void setup() {
// put your setup code here, to run once:
Serial.begin(115200);
if(testMe = 12)
Serial.println("Matches");
else
Serial.println("Does Not Match");
}
void loop() {
// put your main code here, to run repeatedly:
}
Romonaga:
Examine the if statement, it is clearly wrong as we are assigning not comparing. But as this is valid, the compiler and run time will be more than happy to execute this code.
If you turn warnings up to All (as I recommend) at least you get a warning:
sketch_jul26a/sketch_jul26a.ino: In function 'void setup()':
sketch_jul26a/sketch_jul26a.ino:8:18: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
if (testMe = 12)
^
Very true, as the code is in RAM, any error should indicate the line and statement that fouled up...! Often allowing you to edit and continue from the same line after debugging
The downside is that 99% of interpreted languages run significantly slower than precompiled code.
how we will know run time errors if we have problem's on the function of the program...
like i have program for a loop. and the condition get true on wrong way by accidentally and the loop begin... how will we find the error....
Debugging.
The program will crash, or not do what is expected.
You need to apply detective skills to locate - isolate - correct the problem.
In Arduino, debugging is frequently done with Serial.print() statements to display progressive states and values while the program is running