cargaji/tfm-report
cargaji
/
tfm-report
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

checkpoint (last edit of chapters)

This commit is contained in:
Carlos Galindo 2019-12-09 21:47:00 +00:00
parent 20bfa1a8c0
commit 35e170cae6
5 changed files with 66 additions and 146 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

181
Secciones/problem_solution.tex
View File

@ -4,91 +4,25 @@
\chapter{Improving the SDG for exception handling}
\label{cha:solution}
\carlos{This would be useful to explain that the new dependencies introduced by the non-executable edges are not ``normal'' control dependencies, but ``presence'' dependencies. Opposite to traditional control dependence, where $a \ctrldep b$ if and only if the number of times $b$ is executed is dependent on the \textit{execution} of $a$ (e.g. conditional blocks and loops); this new control dependencies exist if and only if the number of times $b$ is executed is dependent on the \textit{presence} or \textit{absence} of $a$; which introduces a meta-problem. In the case of exceptions, it is easy to grasp that the absence of a catch block alters the results of an execution. Same with unconditional jumps, the absence of breaks modifies the flow of the program, but its execution does not control anything. A differentiation seems appropriate, even if only as subcategories of control dependence: execution control dependence and presence control dependence.}
\carlos{This is not really a ``control'' dependence, could be replaced by the definition of structural dependence.}\sergio{Totalmente, pero para decir esto hay que definir la structural dependence, que imagino que estara en la seccion 4.}
This chapter features different problems and weaknesses of the current treatment that program slicing techniques use in presence of exceptions. Each problem is described with a counterexample that illustrates the loss of completeness or precision. Finally, for each problem a solution is proposed.
\deleted{The filter for exceptions in Java's \texttt{catch} blocks is a type (or multiple types since
Java 8), with a class that encompasses all possible exceptions (\texttt{Throwable}), which acts
as a catch-all.
In the literature there exist two alternatives to represent \texttt{catch}: one mimics a static
switch statement, placing all the \texttt{catch} block headers at the same height, all pending
from the exception-throwing exception and the other mimics a dynamic switch or a chain of \texttt{if}
statements. The option chosen affects how control dependencies should be computed, as the different
structures generate different control dependencies by default.}
Regarding the problems, even though the current state of the art considers exception handling, their treatment is not perfect. The mistakes made by program slicers can be classified in two: (1) those that lower the completeness and (2) those that lower the correctness.
\carlos{From here to the end of the chapter, delete / move to solution chapter}
The first kind is the most important one, as the resulting slices may be incorrect (i.e., the behaviour of the slice is different from the behaviour of the original program) making them invalid for some uses of program slicing. A good example of the effects that these wrong slices may produce happens when they are used for program debugging, but the error that we want to debug does not appear any more, or even the slicing criterion cannot be reached due to an uncaught exception.
Regardless of the approach, when there exists a catch--all block, there is no dependence generated
from the \texttt{catch}, as all of them will lead to the next statement. However, this means that
if no data is outputted from the \texttt{try} or \texttt{catch} block, the catches will not be picked
up by the slicing algorithm, which may alter the results unexpectedly. If this problem arises, the
simple and obvious solution would be to add artificial edges to force the inclusion of all \texttt{catch}
blocks, which adds statements to the slice---lowering its score when evaluating against benchmarks---but are completely innocuous as they just stop the exception, without running any extra statement.
Another alternative exists, though, but slows down the process of creating a slice from a SDG.
The \texttt{catch} block is only strictly needed if an exception that it catches may be thrown and
a statement after the \texttt{try-catch} block should be executed; in any other case the \texttt{catch}
block is irrelevant and should not be included. However, this change requires analysing the inclusion
of \texttt{catch} blocks after the two--pass algorithm has completed, slowing it down. In any case, each
approach trades time for accuracy and vice\deleted{--}\added{ }versa, but the trade--off is small enough to be negligible.
Regarding \textit{unchecked} exceptions, an extra layer of analysis should be performed to tag statements
with the possible exceptions they may throw. On top of that, methods must be analysed and tagged
accordingly. The worst case is that of inaccessible methods, which may throw any \texttt{RuntimeException},
but with the source code unavailable, they must be marked as capable of throwing it. This results on
a graph where each statement is dependent on the proper execution of the previous statement; save
for simple statements that may not generate exceptions. The trade--off here is between completeness and
correctness, with the inclusion of \textit{unchecked} exceptions increasing both the completeness and the
slice size, reducing correctness. A possible solution would be to only consider user--generated exceptions
or assume that library methods may never throw an unchecked exception. A new slicing variation that
annotates methods or limits the unchecked exceptions \added{may also}\deleted{to} be considered.
Regarding the \texttt{finally} block, most approaches treat it properly; representing it twice: once
for the case where there is no active exception and another one for the case where it executes with
an exception active. An exception could also be thrown here, but that would be represented normally.
\sergio{Mi aportacion aqui es que posiblemente tenemos que restringir la aproximacion del Chapter 4 diciendo que vamos a tratar solo checked exceptions y mencionar al final que las unchecked serian igual pero anyadiendo mas analisis y mas codigo al slice. Sino cada vez que contemos lo que hacemos vamos a tener que estar diciendo: "y para unchecked noseque..." todo el rato. Cuando presentes la solucion acota el problema y di que vamos a proponer una solucion para checked exceptions y que considera el caso en que no se capture lo que se lanza en el try catch (cosa que puede pasar en java). Eso ya es mejor que la solucion actual}
\deleted{\begin{description}
\item[Switch representation.] There exists no relation between different \texttt{catch} blocks,
each exception-throwing statement is connected through an edge labelled false to each
of the \texttt{catch} blocks that could be entered. Each \texttt{catch} block is a
pseudo-statement, with its true edge connected to the end of the \texttt{try} and the
As an example, a \texttt{1 / 0} expression may be connected to \texttt{ArithmeticException},
\texttt{RuntimeException}, \texttt{Exception} or \texttt{Throwable}.
If any exception may not be caught, there exists a connection to the ``Error exit'' of the method.
\item[If-else representation.] Each exception-throwing statement is connected to the first
\texttt{catch} block. Each \texttt{catch} block is represented as a predicate, with the true
edge connected to the first statement inside the \texttt{catch} block, and the false edge
to the next \texttt{catch} block, until the last one. The last one will be a pseudo-predicate
connected to the first statement after the \texttt{try} if it is a catch-all type or to the
``Error exit'' if it \added{is not}\deleted{isn't}.
\end{description}}
\hrulefill
\josep{This chapter features different problems and weaknesses of the current treatment that program slicing techniques use in presence of exceptions. Each problem is described with a counterexample that illustrates the loss of completeness or precision. Finally, for each problem a solution is proposed.}
\josep{With regards to the problems, }Even though the current state of the art considers exception handling, their treatment is not perfect. The mistakes made by program slicers can be classified in two: \josep{(1)} those that lower the completeness and \josep{(2)} those that lower the correctness. \josep{Remarco el 1 y el 2 porque los referencias mas adelante, lejos, y así se sabe que las referencias vienen aqui.}
The first kind is the most important one, as the resulting slices may be incorrect \josep{(i.e., the behaviour of the slice is different from the behaviour of the original program)\deleted{---as in produce different values than the original program---}} making them invalid for some uses of program slicing. \josep{A good example of the effects that these wrong slices may produce happens when they are used for program debugging, but the the error that we want to debug does not appear anymore, or even the slicing criterion cannot be reached due to an uncaught exception. \deleted{As an example, imagine a slice used for program debugging which does not reach the slicing criterion due to an uncaught exception.}}
The second kind is less \josep{critic\deleted{important}}, but still \josep{important because a wrong treatment of exceptions can cause the inclusion of wrong dependencies in the slice, thus producing unnecessary long slices that may turn to be useless for some applications\deleted{useful to address, as the smaller a slice is, the easier it is to use it}}.
\deleted{The rest of this chapter features different errors found in the state of the art, each with a detailed description, example, and proposals that solve them.}
The second kind is less critical, but still important because a wrong treatment of exceptions can cause the inclusion of wrong dependencies in the slice, thus producing unnecessary long slices that may turn to be useless for some applications.
\section{Unconditional jump handling}
The standard treatment of unconditional jumps as pseudo-statements introduces two separate correctness errors: \josep{\emph{the subsumption correctness error}, which is relevant in the context of both strong and weak slicing, and the \emph{structure-exiting jump}}, \josep{which\deleted{that}} is only relevant in the context of weak slicing.
The standard treatment of unconditional jumps as pseudo-statements introduces two separate correctness errors (type 2): \emph{the subsumption correctness error}, which is relevant in the context of both strong and weak slicing, and the \emph{structure-exiting jump}, that is only relevant in the context of weak slicing.
\subsection{\josep{Problem 1: }Subsumption correctness error}
\subsection{Problem 1: Subsumption correctness error}
This problem has been known since\sergio{Los propios autores lo comentaban? Si es asi no digo nada xD} the seminal publication on slicing unconditional jumps~\cite{BalH93}: chapter 4 details an example where the slice is bigger than it needs to be, and leave the solution of that problem as an open question to be solved in future publications. A similar \sergio{similar a quien? Es similar o el mismo con breaks? yo tal vez diria analogous.}example---with \texttt{break} statements instead of \texttt{goto}---is shown in Example~\ref{exa:problem-break-sub}.
This problem has been known since the seminal publication on slicing unconditional jumps~\cite{BalH93}: the paper's chapter 4 (page 219) details an example where the slice is bigger than it needs to be, and leave the solution of that problem as an open question to be solved in future publications. An analogous example---with \texttt{break} statements instead of \texttt{goto}---is shown in Example~\ref{exa:problem-break-sub}.
\begin{example}[An unconditional jump subsumption~\cite{BalH93}]
\label{exa:problem-break-sub}
Consider the code shown in the left side of Figure~\ref{fig:problem-break-sub}. It is a simple Java method containing a \texttt{while} statement, from which the execution may exit naturally or through any of the \texttt{break} statements (lines 6 and 9). For the rest of statements and expressions\sergio{impacta que ahora digamos statements or expressions cuando llevamos todo el rato diciendo instructions. Casi diria que es la primera vez que nos referimos a expressions. Yo dejaria statements o instructions}, uppercase letters are used; and no data dependencies are considered, as they are not relevant to the problem at hand.
Consider the code shown in the left side of Figure~\ref{fig:problem-break-sub}. It is a simple Java method containing a \texttt{while} statement, from which the execution may exit naturally or through any of the \texttt{break} statements (lines 6 and 9). For the rest of statements and conditional expressions, uppercase letters are used; and no data dependencies are considered, as they are not relevant to the problem at hand.
\begin{figure}[h]
\begin{minipage}{0.33\linewidth}
@ -146,53 +80,45 @@ public void f() {
}
\end{lstlisting}
\end{minipage}
\caption{A program (left), its computed slice (centre) and the \sergio{\{}smallest complete\sergio{\} minimal} slice (right).\sergio{echar un pelin a la derecha, los numeros quedan fuera del margen}}
\caption{A program (left), its computed slice (centre) and the minimal slice (right).}
\label{fig:problem-break-sub}
\end{figure}
Now consider statement \texttt{C} (line 11) as the slicing criterion. Figure~\ref{fig:problem-break-sub-sdg} displays the SDG produced for the program, and the nodes selected by the slice. Figure~\ref{fig:problem-break-sub} displays the computed slice on the centre, and the \josep{minimal slice\deleted{smallest slice possible}} on the left\josep{en realidad hay otro minimal slice si dejamos el otro break y quitamos el que hemos dejado}\sergio{Si decimos minimal slice tenemos que haber dicho que es en algun sitio, al menos definirlo. Lo hemos dicho?}. The inner \texttt{break} on line \josep{6\deleted{9}} and the \texttt{if} surrounding it (line \josep{4\deleted{7}}) have been unnecessarily included. Their inclusion would not be specially problematic, if it were not for the condition of the \texttt{if} statement \josep{(line 4)}, which may include extra data dependencies \josep{that are unnecessary in the slice and that may led to include other unnecessary statements, making the slice even more imprecise\deleted{, whose only task is to control line 3}}.
Now consider statement \texttt{C} (line 11) as the slicing criterion. Figure~\ref{fig:problem-break-sub-sdg} displays the SDG produced for the program, and the nodes selected by the slice. Figure~\ref{fig:problem-break-sub} displays the computed slice on the centre, and one of the minimal slices on the left. The inner \texttt{break} on line 6 and the \texttt{if} surrounding it have been unnecessarily included. Their inclusion would not be specially problematic, if it were not for the condition of the \texttt{if} statement, which may include extra data dependencies that are unnecessary in the slice and that may lead to include other unnecessary statements, making the slice even more imprecise.
Line 6 is not useful, because whether or not it executes, the execution will continue on line 13 (after the \texttt{while}), as guaranteed by line 9, which is not guarded by any condition. Note that \texttt{B} is still control-dependent on line \josep{6\deleted{5}}, as it has a direct effect on it, \josep{no termino de entender esta frase}\sergio{yo entiendo que se refiere a que el inner break (6) tiene control sobre B (8), pero no sobre C. Yo creo que si que se entiende bien}but the dependence \deleted{from line 5 to line 9}\sergio{demasiados line tal line cual}\added{between both \texttt{break} statements} introduces useless statements into the slice.
Line 6 is not useful because regardless of whether it executes, the execution will continue on line 13 (after the \texttt{while}), as guaranteed by the other \texttt{break} statement on line 9, which is not guarded by any condition. Note that \texttt{B} is still control-dependent on line \josep{6\deleted{5}}, as it has a direct effect on it, but the dependence between both \texttt{break} statements introduces useless statements into the slice.
\begin{figure}[h]
\centering
\includegraphics[width=0.5\linewidth]{img/problem-break-sub-graph}
\caption{The system dependence graph for the program of Figure \ref{fig:problem-break-sub}, with the slice marked in grey, and the slicing criterion in bold.\josep{En las condiciones pones O,P,Q en lugar de X,Y,Z}\sergio{eso es porque la liaste en el brainstorming con la O P Q, y lo rompiste todo, Josep's fault!! xD}}
\caption{The system dependence graph for the program of Figure \ref{fig:problem-break-sub}, with the slice marked in grey, and the slicing criterion in bold.}
\label{fig:problem-break-sub-sdg}
\end{figure}
\end{example}
\carlos{Superfluous: edge that connects two equivalent jumps w/o data. Solution: remove it after generating the control dependencies.}
The problem showcased in Example~\ref{exa:problem-break-sub} can be generalized as Problem~\ref{pro:p1} for any pair of unconditional jump statements that are nested and whose destination is the same.
The problem showcased in Example~\ref{exa:problem-break-sub} can be generalized for any pair of unconditional jump statements that are nested and whose destination is the same. Formally, \josep{lo que sigue es bastante lioso. Yo crearia un entorno "problem" (como el de definition o example) y pondria el problema descrito formalmente en ese entorno. Despues, lo aclararia con una breve explicacion similar a la que hay entremezclada con la definicion formal}if a program $P$ contains a pair of unconditional jumps without any data \added{information} (e.g. \texttt{goto label}, \texttt{continue [label]}, \texttt{break [label]}, \texttt{return})\sergio{yo pondria 1, no los 4, que sino ya no es e.g. xD}\josep{Si esos cuatro son exhaustivos dejalos los cuatro, pero cambia e.g. por i.e.} $j_A$ and $j_B$ whose destinations (the instruction that will be executed after them) are $A$ and $B$, then $j_B$ is superfluous in the slice if and only if $A = B$ and $j_B$ is inside a conditional instruction $C$, and $j_A$ follows $C$ (not necessarily immediately). \carlos{Buscar mejor descripcion para la estructura ``nested''.} \carlos{Maybe use control dependencies between them.} Once $j_B$ is included, $C$ will also be included, and so will all of its data dependencies. \sergio{Esta definicion tiene varios vacios, estaba intentando proponer algo pero hay que definir varios conjuntos y es una definicion condicional del SC... propongo intentar hacer una mejor definicion entre los 3 el lunes}
\begin{problem}[Subsumption correctness error]
\label{pro:p1}
Let $a$ and $b$ be two distinct unconditional jump statements without data whose destination $c$ is the same. Any control edge that connects them is superfluous and includes unnecessary statements in the slices produced.
\end{problem}
\sergio{Dejo esto a medias a ver si partiendo de eso sacamos algo:}
\subsubsection*{A solution for the subsumption correctness error}
\sergio{Let $P$ be a program, $C_{block}$ a block contained in a conditional statement $C$ of $P$, and $j_A$ and $j_B$ two unconditional jumps of $P$ without any data (e.g. \texttt{goto label}) which jump to the statements $A$ and $B$ respectively.}
As only the minimum amount of control edges are inserted into the PDG (according to Definition~\ref{def:pdg}), it is only necessary to remove the edge described in Problem~\ref{pro:p1} in order to improve the correctness of the algorithm. This removal must be performed after the SDG has been build, in order to avoid the reappearance of transitive dependencies that are excluded by the PDG's definition.
\sergio{$j_B$ $\in$ Superfluous in the slice w.r.t. SC $\iff$ $A = B$ $\wedge$ $j_B$ $\in$ $C_{Block}$ $\wedge$ $\not\exists$ path $E_P$ $\in$ \{$CFG_P$ from $j_B$ to $SC$\} . $j_A$ $\not\in$ $E_P$}
\subsection{Problem 2: Unnecessary instructions in weak slicing}
\subsubsection*{\josep{\deleted{Proposal}A solution for the subsumption correctness error}}
As only the minimum amount of control edges are inserted into the PDG (according to Definition~\ref{def:pdg}), the only edge that can be traverse to include the inner jump ($j_B$) is an edge $j_B \ctrldep j_A$. An exception can be included when generating the PDG, such that control edges between two unconditional jumps $j_X$ and $j_Y$ whose destinations are $X$ and $Y$ will not be included if $X = Y$.
If the edge is not present, all inner unconditional jumps and their containing structures will be excluded from the slice, unless they are included for another reason.
\josep{pon a continuacion un ejemplo solucionando el problema (al menos di como quedaría el SDG)}
\subsection{\josep{Problem 2: }Unnecessary instructions in weak slicing}
\josep{Esta frase esta mal construida}In the context of weak slicing, as \deleted{it is not necessary to behave exactly like the original program}\added{shown in chapter \ref{cha:incremental}??, the slicing criterion is not forced to behave in exactly the same way that the original program} . This means that some statements may be removed, even if it \deleted{means that a loop will become infinite}\added{results in an infinity loop execution}, or an \deleted{exception will not be caught}\added{uncaught exception behaviour}. The following example describes a specific \deleted{example}\added{scenario} which is generalized later in this section.
In the context of weak slicing, as shown in chapter \ref{cha:incremental}, the slicing criterion is not forced to behave in exactly the same way that the original program. This means that some statements may be removed, even if it results in an infinity loop execution, or an uncaught exception behaviour. The following example describes a specific scenario which is generalized later in this section.
\begin{example}[Unnecessary unconditional jumps]
\label{exa:problem-break-weak}
Consider the code for method \texttt{g} on Figure~\ref{fig:problem-break-weak-code}, which features a simple loop with a \texttt{break} statement within. The slice in the middle has been created with respect to the \added{slicing} criterion $\langle 6, x \rangle$, and includes everything except the print statement. This seems correct, as the presence of lines 4 and 5 determine the number of times line 6 is executed.
Consider the code for method \texttt{g} on Figure~\ref{fig:problem-break-weak-code}, which features a simple loop with a \texttt{break} statement within. The slice in the middle has been created with respect to the slicing criterion $\langle 6, x \rangle$, and includes everything except the print statement. This seems correct, as the presence of lines 4 and 5 determine the number of times line 6 is executed.
However, if \josep{one considers\deleted{you consider}} weak slicing, instead of strong slicing; the loop's termination stops mattering, lines 4 and 5 are no longer relevant. Without them, the slices produce\josep{\deleted{s}} an infinite list \josep{of} natural numbers (0, 1, 2, 3, 4, 5...)\sergio{\{}, but as that is a prefix \josep{suena raro que una lista infinita sea un prefijo de 0-9, mas bien es al reves}of the original program---which outputs the numbers 0 to 9---the program is still a valid slice (pictured on Figure~\ref{fig:problem-break-weak-code}'s right side).\sergio{\}. Fortunately, this represents no inconvenience in the context of weak slicing, since the values given to the slicing criterion for the original program---which is a list with the numbers 0 to 9---is a prefix of the values generated by the slice, fulfilling the requirements of Definition~\ref{XX}Creo que esto estaba en una definicion.}
However, if one considers weak slicing, instead of strong slicing; the loop's termination stops mattering, lines 4 and 5 are no longer relevant. Without them, the slices produce an infinite list of natural numbers (0, 1, 2, 3, 4, 5...).
As the original program's output (the numbers 0 to 9) is a prefix of the natural numbers, the program is still a valid slice (pictured on Figure~\ref{fig:problem-break-weak-code}'s right side). The sequences of values fulfil the requirements of Definition~\ref{def:weak-slice}.
Note that the removal of lines 4 and 5 is only possible if there are no statements in the slice after the \texttt{while} statement. If the slicing criterion \deleted{is}\added{was} line 8, variable \texttt{x}, lines 4 and 5 \deleted{are}\added{would be} required to print the value, as without them, the program would loop indefinitely and never execute line 8.
Note that the removal of lines 4 and 5 is only possible if there are no statements in the slice after the \texttt{while} statement. If the slicing criterion was line 8, variable \texttt{x}, lines 4 and 5 would be required to print the value, as without them, the program would loop indefinitely and never execute line 8.
\begin{figure}[h]
\begin{minipage}{0.33\linewidth}
@ -241,43 +167,34 @@ void g() {
If we try to generalize this problem, it becomes apparent that instructions that jump backwards (e.g., \texttt{continue}) present a problem, as they may add executions in the middle, not at the end (where they can be disregarded in weak slicing). Therefore, not only has the jump to go forwards, but no instruction can be performed after the jump.
Therefore, a forward jump $j$ (e.g., \texttt{break}, \texttt{return [value]}, \texttt{throw [value]}) whose destination is $X$ is not necessary in a slice $S$ if and only \added{if} there is no statement $s \in S$ which is after $X$, meaning that there is a path from $X$ to $s$ in the CFG. \sergio{Si formalizamos mas arriba aqui habria que hacer lo propio.}
\begin{problem}[Unnecessary instructions in weak slicing]
\label{pro:p2}
Let $j$ be an unconditional jump to $X$. $j$ is not necessary in a slice $S$ if there is no statement present in $S$ that may be executed after $X$ in the original program.
\end{problem}
As with the previous error, the problem is not the inclusion of the jump and its controlling conditional instruction, but the inclusion of the data dependencies of the condition guarding the execution of the jump.
\subsubsection*{\josep{\deleted{Proposal}A solution for the unnecessary instructions in weak slicing}}
\subsubsection*{A solution for the unnecessary instructions in weak slicing}
\carlos{Al acabar el slice, se eliminan los saltos incondicionales tras cuyo destino no haya ningun statement en el slice. A continuacion se realiza el slice de nuevo.}
After the slice has been completed, the unconditional jumps are identified. Those jumps after whose destination there are no more instructions are removed, and the slice recomputed. This is repeated until there are no more unconditional jumps that fulfil the condition expressed in Problem~\ref{pro:p2}.
This problem cannot be easily solved, as it is a ``dynamic'' one, requiring information about the completed slice before allowing the removal of unconditional jumps and their dependencies. This means that the cost of this proposal \josep{cannot\deleted{can not}} be offloaded to the creation of the SDG as with the previous one.
\josep{frase incorrecta}Our proposal \deleted{revolves around temporarily remove}\added{is related to the temporal removal of} edges from the SDG: given an SDG of the form \josep{En la definicion de SDG salia esta sextupla?}$G = \langle N, E_c, E_d, E_{in}, E_{out}, E_{call} \rangle$, \added{we} remove from $E_c$ any edge of the form $x \ctrldep y~|~x, y \in N$, where $x$ is an unconditional forward jump; \added{then,} \deleted{perform} the slice \added{is performed} normally; and \deleted{then}\added{finally}---if there is any statement \added{located} after the destination of $x$ in the slice---\added{we} restore the edges removed in the first step and recompute the slice.\sergio{no habia una solucion mejor que esta?, suena un poco a parche poco convincente} The slice would still be linear, because each node would be visited at most once; but the algorithm has a higher complexity, and the removal and restoration of the control edges has a cost; albeit small.
\josep{pon a continuacion un ejemplo solucionando el problema}
The complexity of this solution is higher than the previous one, as it raises the traversal of the slice from a linear time with respect to the number of nodes to $\mathcal{O}(nm)$, where $n$ is the number of nodes and $m$ is the number of unconditional jumps. That is a worst case estimation, as most cases will be close to linear time.
\section{The \texttt{try-catch} statement}
In this section we present an example where the current \deleted{approximation for the}\added{approach used to handle} \texttt{try-catch} statement\josep{s} fails to capture all the correct dependencies \deleted{and excludes}\added{, excluding} from the slice some statements \deleted{which}\added{that} are necessary for a complete slice (both weak and strong). After that, we generalize the set of cases where \deleted{that}\added{the lack of accuracy}\sergio{creo que aqui con ``that" te referias a la precision no?} is a problem and its possible appearances in real-life development. Finally, we propose a solution which\josep{that} properly represent\josep{s} all the dependencies introduced by the \texttt{try-catch}, focusing on producing complete strong slices.
\subsubsection*{The types of control dependence}
\carlos{this subsection snippet could go in another place}
Even though it continues to be used for control dependence, Definition~\ref{def:ctrl-dep} does not have the same meaning when applied to conditional instructions\josep{en todo el documento se debería hablar de statements en lugar de instructions, porque instructions tiene connotación del paradigma imperartivo, mientras que statements engloba el imperartivo y el declarativo} and loops as it has when applied to unconditional jumps and other complex structures, such as the \texttt{switch} and \texttt{try-catch} statements.
Originally, the definition of control dependence signified that the execution of a statement affected whether or not another one executed (or kept executing)\sergio{$\leftarrow$ no se entiende esta frase. Creo que el whether sobra y el parentesis no lo entiendo}. In contrast, unconditional jumps, and \texttt{try-catch} statements' execution do not affect the following instructions; its presence or absence is what generates the control e. For those instructions, control dependencies are still generated with the same edges, but require the addition of extra edges to the CFG \cite{BalH93,AllH03}\sergio{estos son los psedo-predicate edges? Si son los falsos podemos referenciarlos dentro de la tesis, no hara falta irse a los articulos, sino parece que sean unos nuevos edges que no existian hasta le momento}.
In this section we present an example where the current approach used to handle \texttt{try-catch} statements fails to capture all the correct dependencies, excluding from the slice some statements that are necessary for a complete slice (both weak and strong). After that, we generalize the set of cases where the lack of completeness (kind 1) is a problem and its possible appearances in real-life development. Finally, we propose a solution that properly represents all the dependencies introduced by the \texttt{try-catch}, focusing on producing complete strong slices.
\subsection{Problem 3: The lack control dependencies of \texttt{catch} statements}
In the current approximation\sergio{approach?} for exception handling \cite{AllH03}, \texttt{catch} blocks do not have any outgoing dependence leading anywhere except the instructions it contains. This means that, as showcased in chapter~\ref{cha:introduction}, the only way a \texttt{catch} statement may appear in a slice is if \added{the slicing criterion is inside the catch block, or if the value of a variable defined inside the catch block is needed (reaching it by data dependence).}\deleted{there is a data dependence or one of the statements inside it is needed.}
In the current approach for exception handling \cite{AllH03}, \texttt{catch} blocks do not have any outgoing dependence leading anywhere except the instructions it contains. This means that, as showcased in chapter~\ref{cha:introduction}, the only way a \texttt{catch} statement may appear in a slice is if the slicing criterion is inside the catch block, or if the value of a variable defined inside the catch block is needed (reaching it by data dependence).
The only occasion in which \texttt{catch} blocks generate any kind of control dependence is when there is an exception thrown that is not covered by any of the \texttt{catch} blocks, and the function may exit with an exception. In that case, the instructions after the \texttt{try-catch} block are dependent on an uncaught exception not being thrown.\sergio{aqui hay arcos a todos los catch? Si es asi acabar la frase diciendo que se considera esa instruccion dependiente de todos los catch o algo asi para que quede mas claro.}
The only occasion in which \texttt{catch} blocks generate any kind of control dependence is when there is an exception thrown that is not covered by any of the \texttt{catch} blocks, and the function may exit with an exception. In that case, the instructions after the \texttt{try-catch} block are control dependent on every \texttt{catch} statement.
But, compared to the treatment of unconditional \added{jumps?,} exceptions does\josep{do} not match\sergio{quien does not match?} the treatment of \josep{a} \texttt{try-catch} statement: unconditional jumps have a non-executable edge to the instruction that would be executed in their absence; \texttt{catch} statements do not. \josep{Estos tres parrafos estan escritosa con mucha prisa y no se entienden bien}
But, compared to the treatment of unconditional jumps, the lack of \texttt{catch} statements is not treated: unconditional jumps have a non-executable edge to the instruction that would be executed in their absence; \texttt{catch} statements do not.
\begin{example}[\texttt{catch} statements' outgoing dependencies]
\label{exa:catch-no-dep}
Consider the code shown in Figure~\ref{fig:catch-no-dep-code}, which depicts a \texttt{try-catch} where method \texttt{f}, which may throw an exception, is called. The function may throw either a \texttt{ExceptionA}, \texttt{ExceptionB} or \texttt{Exception}-typed exception; and the \texttt{try-catch} considers all three cases, logging the type of exception caught. Additionally, \texttt{f} accesses and modifies a global variable \texttt{x}. \josep{en el codigo no aparece la x. Seria más claro si apareciera}
Consider the code shown in Figure~\ref{fig:catch-no-dep-code}, which depicts a \texttt{try-catch} where method \texttt{f}, which may throw an exception, is called. The function may throw either a \texttt{ExceptionA}, \texttt{ExceptionB} or \texttt{Exception}-typed exception; and the \texttt{try-catch} considers all three cases, logging the type of exception caught. Additionally, \texttt{f} accesses and modifies a global variable \texttt{x} (which is absent from the snippet shown, but will appear in the graphs).
\begin{figure}[h]
\begin{lstlisting}
@ -296,7 +213,7 @@ next;
\label{fig:catch-no-dep-code}
\end{figure}
The CFG and PDG associated to \deleted{that}\added{the} code \added{of Figure~\ref{fig:catch-no-dep-code}} is depicted in Figure~\ref{fig:catch-no-dep-graphs}\added{\footnote{For the sake of clarity, in the PDG of Figure~\ref{fig:catch-no-dep-graphs}, \texttt{log} function calls have been represented as a single node instead of their full node structures.}}. As can be seen, the only two elements that are dependent on any \texttt{catch} are the log statement and the unpacking of \texttt{x}. If the following statement used \texttt{x} in any way, all \texttt{catch} statements would be selected, otherwise they are ignored, and not deemed necessary. It is true that they are normally not necessary; i.e., if the slicing criterion was placed on \texttt{next} (line 10), the whole \texttt{try-catch} would be rightfully ignored; but there exist cases where \texttt{f()} (line 2) would be part of the slice, and the absence of \texttt{catch} statements would result in an incomplete slice.
The CFG and PDG associated to the code of Figure~\ref{fig:catch-no-dep-code}is depicted in Figure~\ref{fig:catch-no-dep-graphs}\footnote{For the sake of clarity, in the PDG of Figure~\ref{fig:catch-no-dep-graphs}, \texttt{log} function calls have been represented as a single node instead of their full node structures.}. As can be seen, the only two elements that are dependent on any \texttt{catch} are the log statement and the unpacking of \texttt{x}. If the following statement used \texttt{x} in any way, all \texttt{catch} statements would be selected, otherwise they are ignored, and not deemed necessary. It is true that they are normally not necessary; i.e., if the slicing criterion was placed on \texttt{next} (line 10), the whole \texttt{try-catch} would be rightfully ignored; but there exist cases where \texttt{f()} (line 2) would be part of the slice, and the absence of \texttt{catch} statements would result in an incomplete slice.
\begin{figure}[h]
\includegraphics[width=\linewidth]{img/catch-no-dep}
@ -306,7 +223,7 @@ next;
\end{example}
\begin{example}[Incorrectly ignored \texttt{catch} statements]
Consider the code in Figure~\ref{fig:incorrect-try-catch-code}, in which \deleted{a method}\added{the method \texttt{f}} is called twice: once inside a \texttt{try-catch} statement, and a second time, outside. \added{As it happened in Example~\ref{exa:catch-no-dep}}, \texttt{f} also accesses and modifies variable \texttt{x}, which is redefined before the second call to \texttt{f}. Exploring this example, we demonstrate how line 3 will be necessary but not included in the slice.
Consider the code in Figure~\ref{fig:incorrect-try-catch-code}, in which the method \texttt{f} is called twice: once inside a \texttt{try-catch} statement, and a second time, outside of it. As it happened in Example~\ref{exa:catch-no-dep}, \texttt{f} also accesses and modifies variable \texttt{x}, which is redefined before the second call to \texttt{f}. Exploring this example, we demonstrate how line 3 will be necessary but not included in the slice.
\begin{figure}[h]
\begin{minipage}{0.5\linewidth}
@ -329,16 +246,16 @@ void f() throws Exception {
}
\end{lstlisting}
\end{minipage}
\caption{A method \josep{\texttt{f}} that may throw exceptions\josep{\deleted{ (\texttt{f})}}, called twice, once surrounded by a \texttt{try-catch} statement, and another time after it. On the right, the definition of \texttt{f}.}
\caption{A method \texttt{f} that may throw exceptions, called twice, once surrounded by a \texttt{try-catch} statement, and another time after it. On the right, the definition of \texttt{f}.}
\label{fig:incorrect-try-catch-code}
\end{figure}
Figure~\ref{fig:incorrect-try-catch-graph} displays the program dependence graph for the snippet of code on the left side of Figure~\ref{fig:incorrect-try-catch-code}. \josep{por que no se incluye el PDG de la parte derecha?}Data dependencies are shown in red, and summary edges\sergio{esto ya tiene una definicion clara en la seccion del SDG??} in blue. The set of nodes filled in grey represent the slice with respect to \deleted{a}\added{the} slicing criterion \added{$\langle 4, x \rangle$} \josep{no usar la misma numeracion en los dos fragmentos de codigo} in method \texttt{f} $\langle 4, x \rangle$\deleted{(line 4, \texttt{x})}\sergio{plantearse si poner los SC asi o dejarlo como (line X, variable Y)}. In the slice, both calls to \texttt{f} and its input (\texttt{x\_in = x}) are included, but the \texttt{catch} block is not present. The execution of the slice may not be the same: if no exception is thrown, there is no change; but if \texttt{x} was odd before entering the snippet, an exception \deleted{will}\added{would} be thrown and not caught, exiting the program prematurely.
Figure~\ref{fig:incorrect-try-catch-graph} displays the program dependence graph for the snippet of code on the left side of Figure~\ref{fig:incorrect-try-catch-code}. The PDG of \texttt{f} is not shown for simplicity. The set of nodes filled in grey represent the slice with respect to the slicing criterion $\langle 4, x \rangle$ in \texttt{f}. In the slice, both calls to \texttt{f} and its input (\texttt{x\_in = x}) are included, but the \texttt{catch} block is not present. The execution of the slice may not be the same: if no exception is thrown, there is no change; but if \texttt{x} was odd before entering the snippet, an exception would be thrown and not caught, exiting the program prematurely.
\begin{figure}[h]
\centering
\includegraphics[width=0.9\linewidth]{img/incorrect-try-catch}
\caption{The \deleted{system dependence graph}\added{SDG} of the left snippet of Figure~\ref{fig:incorrect-try-catch-code}. \texttt{f} and the \deleted{edges that connect to it}\added{associated inter-procedural edges} are not shown for simplicity.}
\caption{The SDG of the left snippet of Figure~\ref{fig:incorrect-try-catch-code}. \texttt{f} and the associated inter-procedural edges are not shown for simplicity.}
\label{fig:incorrect-try-catch-graph}
\end{figure}
\label{exa:incorrect-try-catch-graph}
@ -347,16 +264,20 @@ void f() throws Exception {
\subsubsection*{A solution for the \texttt{catch}'s lack of control dependencies}
\added{In order to solve the drawback exposed above, we propose the} \texttt{catch} statements \added{to be handled as}\deleted{should be handled like} unconditional jumps \added{were in \cite{}}\sergio{pending Cite}: a non-executable edge should connect them to the instruction that would run if they were absent. For \texttt{catch} statements, the non-executable edge would connect them to the \texttt{catch} that contains the most immediate super-type (or multiple); or to the error exit, if no other \texttt{catch} could catch the same exception. This would create a tree-like structure among \texttt{catch} statements, with the root\sergio{root o leave? si es connect to seria leave, sino seria edge connecting the super-type to catch type} of each tree connected to the ``error exit'' of the method. This would generate dependencies between \texttt{catch} statements, and more importantly, dependencies from the \texttt{catch} statements to the instructions that follow the \texttt{try-catch} statement.
In order to solve the drawback exposed above, we propose the \texttt{catch} statements to be handled as unconditional jumps: a non-executable edge should connect them to the instruction that would run if they were absent. There are two possibilities: to the \texttt{catch} that contains the most immediate super-type (or multiple); or to the error exit, if no other \texttt{catch} could catch the same exception.
This creates a tree-like structure among \texttt{catch} statements, with the root of each tree connected to the ``error exit'' of the method. This would generate dependencies between \texttt{catch} statements, and more importantly, dependencies from the \texttt{catch} statements to the instructions that follow the \texttt{try-catch} statement.
Unfortunately, this creates the same behaviour as with unconditional jumps: all the instructions that follow a \texttt{try-catch} structure is dependent on the presence of the \texttt{catch} statements, which in turn are dependent on all the statements that may throw exceptions. In practice, the inclusion of any statement after a \texttt{try-catch} statement would require the slice to include all \texttt{catch} statements, the statements that may throw exceptions, and all the statements required by control or data dependencies. This is a huge number of instructions just for including the \texttt{catch} statements.
\josep{Los tres parrafos que siguen pretenden resumir todo el trabajo y las discusiones que hemos tenido en varias reuniones sobre como tratar el 1 y el 2 para que el catch sea completo y preciso. Evidentemente, en tres parrafos no se puede explicar, y se requiere de una buena explicacion, de un ejemplo, etc. Entiendo que es la falta de tiempo... }
\sergio{Lo que viene a continuacion suena a parche y es una contribucion muy tocha, de hecho es nuestra mejor baza.}Our solution makes slices complete again, but makes them much less correct. \deleted{As a solution for the incorrectness}\added{However, analysing the behaviour of the catch dependencies, we propose a new technique to improve the downgraded accuracy. This technique follow the same basis that the one proposed for unconditional jumps, and consists in the insertion of}\deleted{ we could insert} an additional requirement when including \texttt{catch} blocks: if they are included because of their control dependencies on instructions outside the \texttt{try-catch}, they need to satisfy an additional condition before being in the slice: have a node in the slice which may throw a compatible exception.
We propose two separate solutions in order to reduce the number of statements introduced:
\sergio{Esto hay que pulirlo y anyadir un dibujo con los arcos 1 y 2 en verde. El verde no es importante, es solo una senya de identidad en el dibujo. Lo importante es la etiqueta $\rightarrow$ }
In order to achieve this, control dependencies whose source is a \texttt{catch} node and its destination is outside that same \texttt{catch} are coloured green and labelled (2). Additional edges are added between every \texttt{catch} and any statement that may throw a compatible exception; are also coloured green, and labelled (1). When traversing the graph, only include \texttt{catch} statements if they are reached through an unlabelled edge or if they are reached by at least one edge with each label (1 and 2). \carlos{Add que solo se pueda atravesar uno de los arcos verdes (una vez llegas a un nodo a traves de un arco verde, no continuas recorriendo arcos verdes)} \carlos{optimizacion 2, que los nodos catch se repitan para cada funcion tenga los suyos propios. El contenido del catch es comun a todos, pero las cabeceras y el despempaquetamiento de variables es individual para cada funcion. De este modo no se coge a todas las funciones. Tambien se podria emplear como alternativa a los arcos etiquetados, creando un set de nodos que no tienen padre, y sirven exclusivamente para que las instrucciones futuras dependan de ellas.}
\begin{enumerate}
\item Make the inclusion of \texttt{catch} statements conditional on not one but two dependencies: a statement that throws an exception is present in the slice but also there is a statement that needs the exception to be caught. This would place the minimum amount of \texttt{catch} statements, with the cost of a slower program slicer.
\item Represent each \texttt{catch} statement in multiple nodes, one per method that may lead to it. This would minimize the number of method calls that are included when the corresponding \texttt{catch} block is included, but it may increase considerably the amount of nodes in the SDG.
\end{enumerate}
Both solutions need to be studied further before being implemented, but at least the slices produced are complete, even if some correctness is lost along the way.
% \begin{example}[Order of \texttt{catch} statements]
% Consider the following exception types declared in figure~\ref{fig:catch-order-code}, and their ordering in a simple \texttt{try-catch} statement. The \texttt{catch} blocks may be reorganized in any order if the type

15
Secciones/state_of_the_art.tex
View File

@ -4,18 +4,17 @@
\chapter{Related work}
\label{cha:state-art}
\deleted{S}\added{Program s}licing was proposed \cite{Wei81} and \added{iteratively }improved\sergio{un par de citas de papers intermedios que haya} until the proposal of the current\added{ly} \deleted{system}\added{most used program representation structure,} \deleted{(}the SDG\deleted{)} \carlos{(citation)}. Specifically\added{,} in the context of exceptions, multiple approaches have been attempted\deleted{,} with varying\sergio{diverse?} 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\added{s} \added{was Allen and Horwitz (}\cite{AllH03}\added{)}, although \added{it was} not the first one \deleted{\cite{SinH98,SinHR99}} \deleted{to} target\added{ing} Java \added{programming language} specifically\added{(\cite{SinH98,SinHR99})}.
Program slicing was proposed \cite{Wei81} and iteratively improved until the proposal of the currently most used program representation structure, the SDG. Specifically, in the context of exceptions, multiple approaches have been attempted with varying degrees of success.
In the realm of academia, there exists no definite solution. One of the most relevant initial proposals was Allen and Horwitz (\cite{AllH03}), although it was not the first one targeting the Java programming language specifically (\cite{SinH98,SinHR99}).
\deleted{It}\added{In \cite{AllH03}, Allen and Horwitz benefit from the}\deleted{uses} the existing proposals for \textit{return}, \textit{goto} and other unconditional jumps\sergio{anyadir citas} to model the behavior of \textit{throw} statements. Control flow inside \textit{try-catch-finally} statements \deleted{is}\added{was} simulated, both for explicit \textit{throw} and \added{all possible \textit{throws}} nested inside a method call. \sergio{\{}The base algorithm is presented, and then the proposal is detailed as changes.\sergio{\} useless sentence} \deleted{U}\added{In that work, u}nchecked exceptions \deleted{are}\added{were} considered but regarded as ``worthless'' to include, due to the increase in size of the slices, which reduces their effectiveness \sergio{\{}as a debugging tool\sergio{\}cuidao con esto de debugging tool}. \added{The reason for this decision, was}\deleted{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\added{, which would entail an exhaustive analysis of the code looking for every potential instruction that may arise all kinds of unchecked exceptions}. On top of that, handling \textit{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. \sergio{\{}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 \added{do not}\deleted{don't} affect a slice's precision, only its readability.\sergio{\}$\leftarrow$ delete. Presentamos lo que hicieron, no hay que dar soluciones que no propongamos durante la tesis.}
In \cite{AllH03}, Allen et al. benefit from the existing proposals for \textit{return}, \textit{goto} and other unconditional jumps \cite{HorwitzRB88} to model the behaviour of \textit{throw} statements. Control flow inside \textit{try-catch-finally} statements was simulated, both for explicit \textit{throw} and all possible \textit{throws} nested inside a method call. In that work, unchecked exceptions were considered but regarded as ``worthless'' to include, due to the increase in size of the slices, which reduces their effectiveness. The reason for this decision, was 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, which would entail an exhaustive analysis of the code looking for every potential instruction that may arise all kinds of unchecked exceptions. On top of that, handling \textit{unchecked} exceptions opens the problem of calling an API to which there is no analysable source code, either because the module was compiled before-hand or because it is part of a distributed system.
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.\sergio{Estos curraban con algun lenguaje concreto o con el CFG en general y au?}
Chang et al. \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} describe\deleted{s} 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 \textit{throw} nodes, and introduce handling \textit{catch} nodes as a switch, each trying to catch the exception before deferring onto the next \textit{catch} or propagating it to the calling method. Their proposal is center\added{ed} 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 \textit{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.\sergio{Si nosotros lo hacemos mejor que ellos es bueno momento de echarnos flores. Example (si fuera el caso): their approach was able to add catches to define control dependencies between instructions after the try-catch block and the catch clauses, but their switch like structure forces to include all non-related catch clauses, which made is non usable for Java, where the exception types are represented in a inheritance system.}
Jiang et al. \cite{JiaZSJ06} describe 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 \textit{throw} nodes, and introduce handling \textit{catch} nodes as a switch, each trying to catch the exception before deferring onto the next \textit{catch} or propagating it to the calling method. Their proposal is centred 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 \textit{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 call nodes.
Prabhu et al. \cite{PraMB11} have worked specifically on the C++ exception framework, but without producing any notable improvement to the field that could be applicable to Java.
Others \cite{PraMB11} have worked specifically on the C++ exception framework. \carlos{remove or expand}.\sergio{expand o juntarlo con el de arriba, que es tambien C++, pero decir algo.}
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 \textit{catch} statements, while adding explicit support for virtual calls, polymorphism and inheritance.\sergio{Es completo? trata los casos que solucionamos? se centra en modelar pero no es util para slicing? Extenderlo un poquito mas}
Finally, Jie et al. \cite{JieS11} introduced an 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 \textit{catch} statements, while adding explicit support for virtual calls, polymorphism and inheritance. Despite its reach, it does not solve the original underlying problems displayed in Allen's approach \cite{AllH03}, which is why our thesis is centred around Allen's contribution.
% \hrulefill
% \marginnote{Alternative explanation of \cite{AllH03}, with counter example. Maybe should move the counter example backwards.}

14
img/problem-break-sub-graph.dot
View File

@ -1,20 +1,20 @@
digraph pdf {
entry [label="enter f()",style=filled];
entry -> {while; D};
while [label="while (O)",style=filled];
while [label="while (X)",style=filled];
C [style="bold,filled"]
"if (P)" [style=filled]
"if (Q)" [style=filled]
while -> {"if (P)" C};
"if (Y)" [style=filled]
"if (Z)" [style=filled]
while -> {"if (Y)" C};
break2 [style=filled]
break1 [style=filled]
"if (P)" -> {"if (Q)"};
"if (Q)" -> {A break1};
"if (Y)" -> {"if (Z)"};
"if (Z)" -> {A break1};
break1 -> B;
break1 -> break2;
break2 -> {C while};
{rank=same; A break1 B break2}
{rank=same; "if (Q)" C}
{rank=same; "if (Z)" C}
{rank=same; while D}
{edge [style=invis];
A -> break1 -> B -> break2;

BIN
img/problem-break-sub-graph.pdf
View File

Binary file not shown.

2
paper.tex
View File

@ -76,7 +76,7 @@
\cleardoublepage
\begin{abstract}
Program slicing is an analysis technique that can be applied to practically all programming languages. However, in the presence of exception handling, current program slicing software has a precision problem. In this thesis we tackle the problem of program slicing with exception handling, analysing the problem from a general perspective (for any kind of exception system), but focusing our efforts in the object-oriented paradigm, specifically the Java language. The solution is still general enough to be applicable to other paradigms and programming languages.
Program slicing is an analysis technique that can be applied to practically all programming languages. However, in the presence of exception handling, current program slicing software has a precision problem. This project tackles the problem of program slicing with exception handling, analysing the problem from a general perspective (for any kind of exception system), but focusing our efforts in the object-oriented paradigm, specifically the Java language. The solution is still general enough to be applicable to other paradigms and programming languages.
In this thesis, we study the currently available solutions to the problem, and we propose a generalization that includes at least the \texttt{try-catch} and \texttt{throw} statements. The solution we propose produces slices that guarantee completeness and are as correct as possible. The implementation of the technique proposed will be in Java.