Added more Comments in 3.3.2

Secciones/incremental_slicing.tex

@@ -324,10 +324,11 @@ Inside the \texttt{try} there can be four distinct sources of exceptions:
 		surface inside the \texttt{try} block.
 		As \textit{checked} exceptions must be declared explicitly, method declarations may be consulted to see if a method call may or may not throw any exceptions.
 		On this front, polymorphism and inheritance present no problem, as inherited methods must match the signature of the parent method ---including exceptions that may be thrown.
-		If \textit{unchecked} exceptions are also considered, method calls could be analysed to know which exceptions may be thrown, or the documentation be checked automatically for the comment annotation \texttt{@throws} to know which ones are thrown.
-		\sergio{In case \textit{unchecked} exceptions would be also considered, a further analysis must be done  }
-	\item[\texttt{throw} statements.] The least common, but most simple, as it is treated as a
-		\texttt{throw} inside a method. The type of the exception may be obvious, as most \carlos{this is a weird claim to make without backup} exceptions are built and thrown in the same instruction; but it also may be hidden: e.g., \texttt{throw (Exception) o} where \texttt{o} is a variable of type Object.
+		\deleted{If}\added{In case} \textit{unchecked} exceptions are also considered, method calls could be analysed to know which exceptions may be thrown, or the documentation \added{could} be checked automatically for the comment annotation \texttt{@throws} to know which ones \deleted{are thrown}\added{can be raised}.
+	\item[\texttt{throw} statements.] The least common, but most simple, as it is \deleted{treated as}\added{equivalent to}\sergio{no las tratamos, solo decimos cuales son} a
+		\texttt{throw} inside a method \sergio{Hemos explicado como se trata un ``throw inside un method"? O nos estamos refiriendo a una checked exception en una method call?}. The type of the exception may be obvious, as most \carlos{this is a weird claim to make without backup} exceptions are built and thrown in the same instruction; but it also may be hidden: e.g., \texttt{throw \added{(}(Exception) o\added{)}} where\sergio{por claridad, sino parece que la o forma parte de la frase} \texttt{o} is a variable of type Object.
+		
+		\sergio{Este es el caso mas directo de excepcion, un throw a fuego en un try-catch. Yo tal vez lo pondria antes que las method calls.}
 	\item[Implicit unchecked exceptions.] If \textit{unchecked} exceptions are considered, many
 		common expressions may throw an exception, with the most common ones being trying to call
 		a method or accessing a field of a \texttt{null} object (\texttt{NullPointerException}),
@@ -336,19 +337,21 @@ Inside the \texttt{try} there can be four distinct sources of exceptions:
 		(\texttt{ClassCastException}) and many others. On top of that, the user may create new
 		types that inherit from \texttt{RuntimeException}, but those may only be explicitly thrown.
 		Their inclusion in program slicing and therefore in the method's CFG generates extra
-		dependencies that make the slices produced bigger.
+		dependencies that make the slices produced bigger\added{. For this reason, they are not considered in most of the previous works}.
 	\item[Errors.] May be generated at any point in the execution of the program, but they normally
 		signal a situation from which it may be impossible to recover, such as an internal JVM error.
 		In general, most programs will not attempt to catch them, and can be excluded in order to simplify implicit unchecked exceptions (any instruction at any moment may throw an Error).
+		
+\sergio{Despues de leer las 4 propongo el que me parece el orden ideal de explicacion: (1) throw (2) implicit unchecked (3) method calls (asi puedes aprovechar que ya has hablado de las uncheked ahora mismo y el lector ya ha recordado que eran) (4) errors}
 \end{description}
 
 All exception sources are treated very similarly: the statement that may throw an exception
-is treated as a predicate, with the true edge connected to the next instruction were the statement
-to execute without raising exceptions; and the false edge connected to all the possible \texttt{catch} nodes which may be compatible with the exception thrown.
+is treated as a predicate, with the true edge connected to the next instruction \deleted{were the statement
+to execute without raising exceptions}\added{of the normal execution}; and the false edge connected to all the possible \texttt{catch} nodes which may be compatible with the exception thrown.
 
-The case of method calls that may throw exceptions is slightly different, as there may be variables to unpack, both in the case of a normal or erroneous exit. To that end, nodes containing method calls have an unlimited number of outgoing edges: one to leads to a node labelled ``normal return'', after which the variables produced by any normal exit of the method are unpacked; and all the others to any possible catch that may catch the exception thrown. Each catch must then unpack the variables produced by the erroneous exits of the method.
+\deleted{The case of method calls that may throw exceptions is slightly different, as}\added{Unfortunately, when the exception source is a method call, there is an augmented behavour that make the representation slightly different, since} there may be variables to unpack, both in the case of a normal or erroneous exit. To that end, nodes containing method calls have an unlimited number of outgoing edges: one \deleted{to leads}\added{that points} to a node labelled ``normal return'', after which the variables produced by any normal exit of the method are unpacked; and all the others \added{point} to any possible catch that may catch the exception thrown. Each catch must then unpack the variables produced by the erroneous exits of the method.
 
-The ``normal return'' node is itself a pseudo-statement; with the \textit{true} edge leading to the following instruction and the \textit{false} one to the first common instruction between all the paths of length $\ge 1$ that start from the method call ---which translates to the instruction that follows the \texttt{try} block if all possible exceptions thrown by the method are caught or the ``Exit'' node if there are some left uncaught.
+The ``normal return'' node is itself a pseudo-statement; with the \textit{true} edge leading to the following instruction and \sergio{\{}the \textit{false} one to the first common instruction between all the paths of length $\ge 1$ that start from the method call ---which translates to the instruction that follows the \texttt{try} block if all possible exceptions thrown by the method are caught or the ``Exit'' node if there are some left uncaught.\sergio{\}esta frase es larguisima, con aclaraciones en medio y no se entiende.}
 
 \deleted{Carlos: CATCH Representation doesn't matter, it is similar to a switch but checking against types.
 	The difference exists where there exists the chance of not catching the exception;
@@ -382,9 +385,10 @@ structures generate different control dependencies by default.}
 \end{description}}
 
 \begin{example}[Catches.]
-	Consider the following segment of Java code in figure~\ref{fig:try-catch}, which includes some statements that do not use data (X, Y and Z), and method call to \texttt{f} that uses \texttt{x} and \texttt{y}, two global variables. \texttt{f} may throw an exception, so it has been placed inside a \texttt{try-catch} structure, with a statement in the \texttt{catch} that logs the error when it occurs. Additionally, when \texttt{f} exits without an error, only \texttt{x} is modified; but when an error occurs, only \texttt{y} is modified.
+	Consider the \deleted{following }segment of Java code in figure~\ref{fig:try-catch}\added{ (left)}, which includes some statements \deleted{that do not use data}\added{without any data dependence} (X, Y and Z), and\added{a} method call to \texttt{f} that uses \texttt{x} and \texttt{y}, two global variables. \texttt{f} may throw an exception, so it has been placed inside a \texttt{try-catch} structure, with a statement in the \texttt{catch} that logs the \added{\texttt{error}} \added{token} when it occurs. Additionally, \added{consider the case that} when \texttt{f} exits \deleted{without an error}\added{normally}, only \texttt{x} is modified; but when an error occurs, only \texttt{y} is modified.
 
-	Note how the pseudo-statements act to create control dependencies between the \textit{true} and \textit{false} edges, such as the ``normal return'', ``catch'', ``try''. The statements contained after the function call, inside the \texttt{catch} and the \texttt{try} blocks are respectively control dependent on the aforementioned nodes. Finally, consider the statement \texttt{Z}; which is not dependent on any part of the \texttt{try-catch} block, as all exceptions that may be thrown are caught: it will execute regardless of the path taken inside the \texttt{try} block. \carlos{Consider critiquing the result, saying that despite the last sentence, statements can be removed (the catch) so that the dependencies are no longer the same.}
+	\deleted{Note how the pseudo-statements act to create control dependencies between the \textit{true} and \textit{false} edges, such as the ``normal return'', ``catch'', ``try''.}\added{As can be seen in the CFG shown in figure~\ref{fig:try-catch} (centre), the nodes ``normal return'', ``catch'' and ``try'' are considered as pseudo-statements, and their \textit{true} and \textit{false} edges (solid and dashed arrows respectively) are used to create control dependencies.} The statements contained after the function call, inside the \texttt{catch} \added{block,} and \added{inside} the \texttt{try} block\deleted{s} are respectively control dependent on the aforementioned nodes.
+	 Finally, consider the statement \texttt{Z}; which is not dependent on any part of the \texttt{try-catch} block, as all exceptions that may be thrown are caught: it will execute regardless of the path taken inside the \texttt{try} block. \carlos{Consider critiquing the result, saying that despite the last sentence, statements can be removed (the catch) so that the dependencies are no longer the same.}
 	\begin{figure}[h]
 	\begin{minipage}{0.35\linewidth}
 		\begin{lstlisting}
@@ -421,7 +425,7 @@ The \texttt{catch} block is only strictly needed if an exception that it catches
 an instruction 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--versa, but the trade--off is small enough to be negligible.
+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
@@ -432,11 +436,13 @@ for simple statements that may not generate exceptions. The trade--off here is b
 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 to be considered.
+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}
+
 % vim: set noexpandtab:ts=2:sw=2:wrap