0

For comparison, for a runtime fatal error, it is often that the cause of the error is way before the error crashes a program.

For a logic error, it doesn't crash a program. It happens when the state of the execution of the program isn't what we expect for the first time. The cause of a logic error in a program, I think, just like the cause of a runtime fatal error, is where you make correction and the program will not have the logic error. I wonder if the cause of a logic error must be where the error happens, or can be way before that?

Thanks.

  • Of course. I just fixed an error in some code that loaded some data. The bug manifested later, when the data was used to calculate something. – Blorgbeard Sep 12 '14 at 2:19
  • in "some code that loaded data", why doesn't the error manifiest? – Tim Sep 12 '14 at 2:20
  • Because it was a logic error - it loaded the data into the wrong fields. Nothing happened until later, because nobody tried to use the fields until later. – Blorgbeard Sep 12 '14 at 2:23
  • when "it loaded the data into the wrong fields", why isn't that "manifest" of the error? – Tim Sep 12 '14 at 2:24
  • Because nothing appeared to be wrong at that point, to the user. If you define "manifest" to mean "when the bug occurred", then of course a bug can't occur earlier than it occurs.. – Blorgbeard Sep 12 '14 at 2:27
2

I guess your problem is more a linguistic one - the term "logic error" is very vague, and the term "time when it happens" can mean different things to different people.

Let's say you write a simple calculator program. It will allow you to enter something like "1+2" by the keyboard, calculate and display the result. Now you enter "1+2" and it displays not the expected value 3, but 4. So exactly "when" does this logic error happen? From the users point of view, it happens just when he or she sees the wrong result.

But the cause can be anywhere beforehand - the input data could be parsed wrong, the calculation itself could have gone wrong, or the display on the screen had a bug. So from the users point of view, the cause for the error is somewhere "before it happens". However, from a developers point of view who uses a debugger single-stepping through the program, the "state of the execution of the program" is wrong immediately at the time when the input parser delivers a wrong result, or the calculation delivers a wrong result, or the code bringing the result to the display does something wrong. So from this perspective, the logic error's cause is exactly where the internal state of the program deviates from the expected value.

1

These are the same thing. A runtime fatal error is (excluding malicious programmers and cosmic rays) always the result of a logic error -- somewhere, the program assumed something that wasn't true and then when trying to do simething based upon the false premise, causes a fatal error.

The assumption and its consequences can of course be widely seperated in both time and flow.

  • thanks. (1) what is "assumption" here? (2) isn't it true that "time" and "flow" correspond to each other in a one-to-one manner? – Tim Sep 12 '14 at 2:36
  • 1
    @Tim: (1) the assumption refers to the logic flaw. And (2) No. Flow refers to program flow -- additional functions called. Say you have a function that populates a list of strings as numbers, and a function that turns the elements of list of strings into a number and does some processing on it. If the first function mistakenly puts a non number into the list, the second will crash. logic error in first function, runtime error in second. These functions could be the same function, in which case flow-wise they are very close, but with a large list, possibly very far apart in time. – jmoreno Sep 12 '14 at 2:59
  • A runtime fatal error is not always caused by a logic error. it can be originated by a hardware fault. – Tulains Córdova Sep 12 '14 at 4:52
  • @user61852: I think that is adequately covered by "cosmic rays". Either the hardware fault is no more under the applications control than cosmic rays are, or it's a failure to account for a possible failure. Back in the day, I wrote code to deal with the application disk suddenly not being available during an open dialog. Not really hardware fault, more user action, but same thing: you either account for it or you don't. Nowdays I don't, I don't go looking for it and if I encountered it, I'd probably say tough, get a hard drive, as that is by far the simpler solution. – jmoreno Sep 12 '14 at 5:21

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