70 lines
5.7 KiB
TeX
70 lines
5.7 KiB
TeX
% !TEX encoding = UTF-8
|
|
% !TEX spellcheck = en_GB
|
|
% !TEX root = paper.tex
|
|
\chapter{State of the art}
|
|
|
|
Slicing was proposed\cite{Wei81} and improved until the proposal of the current system (the SDG) \carlos{(citation)}. Specifically in the context of exceptions, multiple approaches have been attempted, with varying degrees of success. There exist commercial solutions for various programming languages: \carlos{name them and link}.
|
|
In the realm of academia, there exists no definite solution. One of the most relevant initial proposal\cite{AllH03}, although not the first one\cite{SinH98,SinHR99} to target Java specifically.
|
|
|
|
It uses the existing proposals for \textsl{return}, \textsl{goto} and other unconditional jumps to model the behavior of \textsl{throw} statements. Control flow inside \textsl{try-catch-finally} statements is simulated, both for explicit \textsl{throw} and those nested inside a method call. The base algorithm is presented, and then the proposal is detailed as changes. Unchecked exceptions are considered but regarded as ``worthless'' to include, due to the increase in size of the slices, which reduces their effectiveness as a debugging tool. This is due to the number of unchecked exceptions embedded in normal Java instructions, such as \texttt{NullException} in any instance field or method, \texttt{IndexOutOfBoundsException} in array accesses and countless others. On top of that, handling \textsl{unchecked} exceptions opens the problem of calling an API to which there is no analyzable source code, either because the module was compiled before-hand or because it is part of a distributed system. The first should not be an obstacle, as class files can be easily decompiled. The only information that may be lost is variable names and comments, which don't affect a slice's precision, only its readability.
|
|
|
|
Chang and Jo\cite{JoC04} present an alternative to the CFG by computing exception-induced control flow separately from the traditional control flow computation, but go no further into the ramifications it entails for the PDG and the SDG.
|
|
|
|
Jiang et al.\cite{JiaZSJ06} describes a solution specific for the exception system in C++, which differs from Java's implementation of exceptions. They reuse the idea of non-executable edges in \textsl{throw} nodes, and introduce handling \textsl{catch} nodes as a switch, each trying to catch the exception before deferring onto the next \textsl{catch} or propagating it to the calling method. Their proposal is center around the IECFG (Improved Exception Control-Flow Graph), which propagates control dependencies onto the PDG and then the SDG. Finally, in their SDG, each normal and exceptional return and their data output are connected to all \textsl{catch} statements where the data may have arrived, which is fine for the example they propose, but could be inefficient if the method has many different call nodes.
|
|
|
|
Others\cite{PraMB11} have worked specifically on the C++ exception framework. \carlos{remove or expand}.
|
|
|
|
Finally, Hao\cite{JieS11} introduced a Object-Oriented System Dependence Graph with exception handling (EOSDG), which represented a generic object-oriented language, with exception handling capabilities. Its broadness allows for the EOSDG to fit into both Java and C++. It uses concepts from Jiang\cite{JiaZSJ06}, such as cascading \textsl{catch} statements, while adding explicit support for virtual calls, polymorphism and inheritance.
|
|
|
|
% TODO UNCOMPLETE
|
|
|
|
\hrulefill
|
|
\marginnote{Alternative explanation of \cite{AllH03}, with counter example. Maybe should move the counter example backwards.}
|
|
|
|
In her paper, Horwitz suggests treating exceptions in the following way:
|
|
\begin{itemize}
|
|
\item Statements are divided into statements, predicates (loops and conditional blocks) and pseudo-predicates (return and throw statements). Statements only have one successor in the CFG, predicates have two (one when the condition is true and another when false), pseudo-predicates have two, but the one labeled ``false'' is non-executable. The non-executable edge connects to the statement that would be executed if the unconditional jump was replaced by a ``nop''.
|
|
\item \textsl{try-catch-finally} blocks are treated differently, but it has fewer dependencies than needed. Each catch block is control-dependent on any statement that may throw the corresponding exception. The
|
|
\end{itemize}
|
|
|
|
\begin{lstlisting}[title=Example]
|
|
void main() {
|
|
int x = 0;
|
|
while (true) {
|
|
try {
|
|
f(x);
|
|
} catch (ExceptionA e) {
|
|
x--;
|
|
} catch (ExceptionB e) {
|
|
System.err.println(x);
|
|
} catch (ExceptionC e) {
|
|
System.out.println(x);
|
|
}
|
|
System.out.println(x);
|
|
}
|
|
}
|
|
|
|
void f(x) {
|
|
x--;
|
|
if (x > 10)
|
|
throw new ExceptionA();
|
|
else if (x == 0)
|
|
throw new ExceptionB();
|
|
else if (x > 0)
|
|
throw new ExceptionC();
|
|
x++;
|
|
System.out.println(x);
|
|
}
|
|
|
|
static class ExceptionA extends ExceptionC {}
|
|
static class ExceptionB extends Exception {}
|
|
static class ExceptionC extends Exception {}
|
|
\end{lstlisting}
|
|
|
|
In this example we can explore all the errors found with the current state of the art.
|
|
|
|
The first problem found is the lack of \texttt{catch} statements in the slice, as no edge is drawn from the catch. Some of the catch blocks will be included via data dependencies, but some may not be reached, though they are still necessary if the slice includes anything after a caught exception.
|
|
Therefore, an extra control dependency must be introduced, in order to always include a ``catch'' statement in the slice if the ``throw'' statement is in the slice. In the example, only the catch statement from line 20 will be included, and if ExceptionC or ExceptionB were thrown, they would not be caught. That would not be a problem if the function $f$ was not executed again, but it is, making the slice incorrect.
|
|
|
|
% vim: set noexpandtab:ts=2:sw=2:wrap
|