Programming Errors Errors of different types Syntax errors

  • Slides: 6
Download presentation
Programming Errors

Programming Errors

Errors of different types • Syntax errors – easiest to fix, found by compiler

Errors of different types • Syntax errors – easiest to fix, found by compiler or interpreter • Semantic errors – logic errors, found by comparing results of test runs to expected results • Runtime errors – errors caused by the environment, bad input, nonexistent files – found by the operating system usually

Syntax errors • Syntax = rules of a language that state how to write

Syntax errors • Syntax = rules of a language that state how to write statements in the language • You learned English syntax when you were in 3 rd – 5 th grades – punctuation, spelling, sentence diagramming • Humans use English syntax but can manage if rules are broken • E. E. Cummings = poet – did not follow English syntax rules well • Computer language translators follow syntax rules rigidly • Punctuation, order of statements, spelling of keywords, etc. must be correct • Give instant feedback when error is detected • Syntax rules do not tell you WHAT to say, just HOW to say it

Semantic errors • Errors in meaning • In English, there are lots of redundancies

Semantic errors • Errors in meaning • In English, there are lots of redundancies to prevent these kinds of errors – “subject number must agree with verb number”, “tenses must agree”, “pronouns must have noun to refer to” • Computer languages – the semantics of a program is exactly “What does this program do when it is executed? ” What does it make the computer do? Does it put something on the screen? Make a noise? Change something in memory? So it is very precise – every language has a standard document which specifies the semantics for every keyword • The translators do NOT detect semantic errors!

How do you find semantic (logic) errors? • Testing! Lots of testing! • You

How do you find semantic (logic) errors? • Testing! Lots of testing! • You develop a plan for testing which includes • A description of the situation to be tested, e. g. “input file is empty” • The Input given to cause this situation to happen, e. g. “a file with nothing in it” • The expected output, e. g. “The program will stop with a message about no data” • Then you run the program with those inputs and record what really happened “actual output” “The program crashed!” • The better your test cases, the more certain you can be that your program is working correctly • Can you prove a program has NO errors? For any program more than a few lines long, the answer is no

Runtime errors • Usually caused by the environment • “file not found” • “Network

Runtime errors • Usually caused by the environment • “file not found” • “Network connect is missing” • “Insufficient data in file” • Generally these will cause the program to halt with ugly error messages • It is possible to program in such a way that these errors can be found by the program while it’s running – it is not easy. • If found by the program, they are usually reported to the user and the program terminated – sometimes default value can be substituted for the missing items, etc.