A logical error, contrary to a fatal runtime error, is a run time error which doesn't fatally terminate a program, but does something not intended.

Is a logical error necessarily caused by the line of code for the earliest state which is wrong?

Or can a logical error be caused by a line of code before the line for the earliest wrong state?

My question mainly comes from

  • I think debugging can only help to tell if a state of a program is right or wrong, and not beyond that.

  • I guess by debugging we can locate the line of code that causes a logical error, because I think a logical error is always caused by the line of code for the earliest state which is wrong, not by a line of code that precedes the line of code for the earliest state which is wrong.

I will be wrong if you provide an example of logical error whose cause can't be found by using a debugger to track the states of the program. In other words, can you provide an example of logical error whose cause is earlier than the earliest states of the program which is wrong?

  • 1
    What is the notion of logical error that you are using? Wikipedia says a logical error is a fallacy, but that relates to the field of logical reasoning rather than to programming. Btw, someone (i.e. me) might consider design errors to be logical errors. Design errors pretty much can't be attributed to a single line of code. – Erik Eidt Oct 29 '15 at 23:34
  • While "logic error" has a reasonably specific meaning in programming, this question remains ambiguous. Many (most?) logic errors are caused by two or more parts of the program disagreeing about how something should be done, and judging which (if any) part of the code was right or wrong in its assumptions is the sort of difficult, subjective choice that separates "software developers" from "code monkeys". – Ixrec Oct 29 '15 at 23:39
  • @Erik: a logical error allows a program to run and exit normally (contrary to fatal runtime error), but the program doesn't do what it is supposed to do. When checking if a program state is correct or wrong, if the state is intended (the values of all objects in all frames are as intended at that point of program execution), then it is correct, and if not, it is wrong. – Tim Oct 29 '15 at 23:39
  • A simple example of a logic error we recently had that was very far away from the root cause: Our program has model objects. We have validation code for these model objects. One day a user loaded a model that was missing required properties after validation. Our views did the wrong thing because they assumed they would always get valid models. Turned out our validation code was horribly broken and we've had dozens of slightly invalid models in our database for months. Oops. – Ixrec Oct 29 '15 at 23:42
  • 2
    If the program contains two (or more) parts that disagree on how something is handled, that program itself is in a state of error before it even begins execution. – Erik Eidt Oct 29 '15 at 23:51

By your wording, you have defined your answer to be true.

You talk about the first "wrong state." What defines a wrong state? What makes it wrong? Typically the answer is "it wasn't the state that was correct." By definition, the first wrong state is preceded by only correct states (or something went wrong on the first step, but that starts to be an OS issue). Thus there is a transition from a right state to a wrong state.

If you assume that the only thing which can change a state is a statement (line of code), then by definition the statement which has just completed and resulted in the first wrong state is "the problem."

These assumptions are not always valid. For example, its trivial to show that if you use a "memory trainer" which allows one program to push values into another program's memory space, any error caused by this trainer is clearly not caused by any line of code at all!

Also, it is possible to have cases where there is no one line "causing" the problem. One such example is a multithreading race case. In such a case it is not always possible to specify which thread "caused" the problem, because the problem actually originated from the interaction between two threads to cause a "wrong state." Since statements (lines of code) are executed on a thread, and the error is not "on a thread," no line of code is at fault.

A more "constructive" approach might be to change the wording. Instead of talking about "the line which caused the error," think about "The line which should be changed to fix the error." That wording changes things up just enough to avoid a blame-game.

This is also very important for dealing with memory bugs. In the case of those bugs, it is often very difficult to identify the actual first "wrong state," but easy to identify the state which segfaults. It's easy to accidentally presume the error had to be some line of code near where it segfaulted because you presume the segfault is the first "wrong state" and forget to look for the actual root cause.


Just to confuse things, if you delete an essential line of code from a program, then it will malfunction.

Once you have done this, the logical error in the code will not be down to any line in the program. It will be caused by the absence of a line.


Consider this: an algorithm that is either inadequate or premature. That is, when this algorithm is executed, it will go through only a subset of the valid states, leaving some valid states unvisited. In doing so, it will miss the correct answer; therefore, when the algorithm finishes, it will finish in a state (*) that is different from the correct state.

(*) I consider the return value to be considered part of the state.

Example: an algorithm that tries to search for a particular integer value in an integer array.

The algorithm contains a defect, such that it only search for items located on even-numbered index values. Items on odd-numbered index values aren't visited.

The visiting of elements on even indices comprises of valid states. However, the lack of visiting of elements on odd indices is an omission that lead to wrong result.

The logic error lies in incorrect state transitions that cause it to skip over indices.

Because a debugger user is able to step through the program execution, the user is able to see both incorrect states being entered, as well as state transitions that are incorrect. Therefore, the error mentioned above is catchable by using a debugger.

However, for non-trivial algorithmic inadequacies (using an algorithm that is unfit for the task), the logic error can only be seen by a person who (1) knows what algorithm is being implemented in the code, and (2) knows that the implementation will fall short of the requirements of the program. This is the case where "debugging" happens on paper, before any line of code is written.

Not the answer you're looking for? Browse other questions tagged or ask your own question.