(computer science) An error, distinct from syntax errors and runtime errors, resulting in compiled or interpreted algorithms performing in ways other than intended. Unlike syntax errors, logic errors are not discovered at compile time, and unlike runtime errors, logic errors invoke no error messages or error handling subprograms, making them particularly hard to detect.
(Logic errors may, and often will, especially when working with programming languages that allow a fair bit of control over the memory, such as C/C++, indirectly trigger runtime errors. In fact, one could argue that run-time errors are essentially the result of severe logic errors. Paradoxically, logic errors that do not cause run-time errors are the hardest to diagnose and locate.)
It is important to note that logic errors are not perceived as errors by the computer. Software containing logic errors will function, but it will do so in an undesirable manner.
Logic errors are caused by anything from design flaws to omission of a semicolon in C and similar languages (in cases where this does not result in a syntax error). Absence of a structured approach and a reluctance to plan ahead are underlying factors.
As previously stated, logic errors are often hard to detect, partly since they may become evident with only a limited range of input. Logic errors constitute a large portion of software bugs. When evident, the error normally manifests itself by causing the software to generate erroneous output or otherwise behave in unexpected ways. This includes (but is far from limited to) performing incorrect calculations; displaying irrelevant output; failing to handle identification, validation and authentication processes properly; and corrupting data.
When a logic error has been discovered, the first priority is to identify the flawed piece of code. Unless one can guess or estimate the origin of the problem based on its characteristics, there are relatively few shortcuts. Performing tests with batches of well-chosen input data may provide sufficient hints to further narrow the scope of code that needs to be manually parsed, because manual parsing (or perhaps stepping through code in a line-by-line fashion as some IDEs as well as the famous gdb allow) is really the only way to combat logic errors. Well, there is one other way, which is even better: stop them before they stop you.
Logic error prevention is associated with most good software development practices. By carefully tracing flowcharts (You did make a systems analysis flowchart, did you not?) before moving on in the software development cycle, and similarly trace all pseudocode algorithms (Please tell me you wrote your pseudocode during the software design phase!) before proceeding to construct the software, one can eliminate most glitches.
Perform top-down analysis. Document, document, comment your code, and document some more. Develop more modular software. Choose life. Use OOP for projects where it is appropriate (i.e. most large-scale projects and some smaller projects). Wear sunscreen. Pick your variable names carefully and in a consistent manner. Use global variables discriminately (if at all). Avoid spaghetti code at all cost, even if your life for some unfathomable reason should depend on it. Planning, structure and testing at all stages is everything.