% !TEX encoding = UTF-8 % !TEX spellcheck = en_US % !TEX root = ../paper.tex \chapter{Introduction} \label{cha:introduction} \section{Motivation} \label{sec:motivation} Program slicing~\cite{Wei81} is a debugging technique \deleted{which}\added{that}, given a line of code and a \added{set of} variable\added{s} of a program, simplifies such program so that the only parts left of it are those that affect \added{or are affected by} the value\added{s} of the selected variable\added{s}. \begin{example}[Program slicing in a simple method] If the following program is sliced on \added{(line 5, variable \texttt{x})} \deleted{line 5 (variable \texttt{x})}, the result would be the program of\josep{at?} the right, with the \texttt{if} block skipped, as it \added{does not}\deleted{doesn't} affect the value of \texttt{x}. \label{exa:program-slicing} \begin{center} \begin{minipage}{0.49\linewidth} \begin{lstlisting}[stepnumber=1] void f(int x) { if (x < 0) System.err.println(x); x++; System.out.println(x); } \end{lstlisting} \end{minipage} \begin{minipage}{0.49\linewidth} \begin{lstlisting}[stepnumber=1] void f(int x) { x++; System.out.println(x); } \end{lstlisting} \end{minipage} \end{center} \end{example} Slices are \deleted{an} executable program\added{s} whose execution \deleted{will} produce\added{s} the same values for the specified line and variable as the original program, and \added{they} are used to facilitate debugging of large and complex programs, where the data flow may not be easily understandable. Though it may seem a really powerful technique, the whole Java language is not completely covered by it, and that makes it difficult to apply in practical settings. An area that has been investigated, yet \added{does not}\deleted{doesn't} have a definitive solution yet is exception handling. Example~\ref{exa:program-slicing2} demonstrates how, even using the latest developments in program slicing~\cite{Allen03}, the sliced version \added{does not}\deleted{doesn't} include the catch block, and therefore \added{does not}\deleted{doesn't} produce a correct slice. \begin{example}[Program slicing with examples] If the following program is sliced \josep{aqui podria colar no decir qué algoritmo usas (el de Horwitz, con su cita), pero en el paper no colará. Ponlo ya, no hace falta que lo expliques aún, pero así eres preciso.} \added{with respect to}\deleted{in} \added{(}line 17, variable \texttt{x}\added{)}, the slice is incomplete, as it lacks the \texttt{catch} block from lines 4-6. \label{exa:program-slicing2} \begin{center} \begin{minipage}{0.49\linewidth} \begin{lstlisting}[stepnumber=1] void f(int x) { try { g(x); } catch (RuntimeException e) { System.err.println("Error"); } System.out.println("g() was ok"); g(x); } void g(int x) { if (x < 0) { throw new RuntimeException(); } System.out.println(x); } \end{lstlisting} \end{minipage} \begin{minipage}{0.49\linewidth} \begin{lstlisting}[stepnumber=1] void f(int x) { try { g(x); } g(x); } void g(int x) { if (x < 0) { throw new RuntimeException(); } System.out.println(x); } \end{lstlisting} \end{minipage} \end{center} \end{example} \josep{Explicar mejor el ejemplo. Ser generoso dando detalles, la ejecución, la diferencia, incluso el grafo de dependencias si hace falta... El motivating example es la parte mas importante de un paper. :-) Determina si van a seguir leyendote o no.} \added{If we consider the initial call {\tt f(-1)}, then the execution history of the initial program is: {\tt 1,2,3,13,14,15,4,5,6,7,8,9,10,13,14,15} (line 17 is never executed and {\tt f} returns with an exception). In contrast, the execution of the slice is: {\tt 1,2,3,13,14,15} (line 17 is never executed and {\tt f} returns with an exception).} \josep{Si no me he equivocado con esto anterior, este es un mal ejemplo, porque no se ejecuta el CS en ninguno de los dos programas (luego son equivalentes con respecto a ese punto con la informacion que das)} \josep{Lo siguiente me suena raro (el ingles). De hecho, no aparece ni una ocurrencia en Google. Reescribelo, please. Es dificil de entender.}As big a problem as this one is, it \added{does not}\deleted{doesn't} occur in all cases, because of how \texttt{catch} blocks are generally treated when slicing. Generally, two kinds of dependencies among statements are analyzed: control (on the result of this line may depend whether another one executes or not) and data (on the result of this line, the inputs for another one may change). The problem described \added{does not}\deleted{doesn't} occur when \deleted{there exist outgoing data dependencies inside the \texttt{try} block}\deleted{the inside the \texttt{try} block there exist outgoing data dependencies}, but it does when there \added{are not}\deleted{aren't}, creating problems for structures with side effects such as a write action to a file or database, or a network request whose result \added{is not}\deleted{isn't} used outside the \texttt{try}. As most slicing tools ignore side effects and focus exclusively on the code and some \texttt{catch} blocks are erroneously removed, which leads to incomplete slices, which end with an error that is normally caught. \section{Contributions} The main contribution of this paper is a complete \added{technique}\deleted{solution} for program slicing in the presence of exception handling constructs for Java\added{. This technique extends the previous technique by Hortwitz et al. \cite{pending}. It considers all cases considered in that work, but it also provides a solution to cases not considered by them.} \added{For the sake of completeness and in order to understand the process that leaded us to this solution, firstly,} we will \added{briefly} present a history of program slicing, specifically those changes that have affected exception handling. Furthermore, we provide a summary of the different contributions each author has made to the field. The rest of the paper is structured as follows: chapter~\ref{cha:background} summarizes the theoretical background required, \josep{y chapter 3?} chapter~\ref{cha:state-art} provides a bird's eye view of the current state of the art, chapter~\ref{cha:solution} provides a step by step description of the problems found with the state of the art and the solutions proposed, and chapter~\ref{cha:conclusion} summarizes the paper and provides avenues of future work. % vim: set noexpandtab:tabstop=2:shiftwidth=2:softtabstop=2:wrap