text: This paper presents a logic based approach to debugging Java programs. In contrast with traditional debugging we propose a debugging methodology for Java programs using logical queries on individual execution states and also over the history of execution. These queries were arrived at by a systematic study of errors in object-oriented programs in our earlier research. We represent the salient events during the execution of a Java program by a logic database, and implement the queries as logic programs. Such an approach allows us to answer a number of useful and interesting queries about a Java program, such as the calling sequence that results in a certain outcome, the state of an object at a particular execution point, etc. Our system also provides the ability to compose new queries during a debugging session. We believe that logic programming offers a significant contribution to the art of object-oriented programs debugging.
  @cite_4: Debugging is still among the most common and costly of programming activities. One reason is that current debugging tools do not directly support the inquisitive nature of the activity. Interrogative Debugging is a new debugging paradigm in which programmers can ask why did and even why didn't questions directly about their program's runtime failures. The Whyline is a prototype Interrogative Debugging interface for the Alice programming environment that visualizes answers in terms of runtime events directly relevant to a programmer's question. Comparisons of identical debugging scenarios from user tests with and without the Whyline showed that the Whyline reduced debugging time by nearly a factor of 8, and helped programmers complete 40 more tasks.
summary: WhyLine @cite_4 is an interrogative debugger for the Alice programming environment. It allows the user to ask why a given event did or did not occur. The WhyLine gives the answer in the form of an execution path that leads or was supposed to lead to the execution of the given event. The path is annotated with control flow information. The comparison among these systems are based on four features: (1) automatic program trace extraction; (2) program trace navigation features such as forwards and backwards stepping, breakpoint, and conditional breakpoint; (3) query language support; (4) built-in trace analyses including a set of the most recurring debugging queries or abstract views of program behavior. Table shows the comparison among the 10 system. JavaTA currently does not support trace navigation; however, it is straight forward to implement. Opium supports similar features as JavaTA especially the built-in trace analyses; however, these analyses are hard to be compared since they target two different programming paradigms namely declarative and imperative respectively.