final change

This commit is contained in:
Carlos Galindo 2019-12-09 22:37:46 +00:00
parent 0481711321
commit 49d736cd80
3 changed files with 28 additions and 7 deletions

View file

@ -268,6 +268,7 @@ In our work we focus on the Java programming language, so in the following, we d
\footnotetext{Only available from Java 7 onward. For more details, see \url{https://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html} (retrieved November 2019).}
\subsection{Exception handling in other programming languages}
\label{sec:exception-others}
In almost all programming languages, errors can appear (either through the
developer, the user or the system's fault), and must be dealt with. Most of the

View file

@ -5,4 +5,18 @@
\chapter{Conclusions}
\label{cha:conclusion}
\carlos{todo: future work (implementacion, mejora de la correcteness para el try-catch), soluciones aportadas (problemas detectados de completitud, de correccion y generalizacion, propuesta solucion de las generalizaciones), valor de la tesis}
Program slicing is a powerful technique to extract subsets of statements from a program, which behave as the original with respect to a slicing criterion. In the past four decades, different techniques have been proposed and matured, among which the system dependence graph is the most popular. The SDG has been implemented for various programming languages and paradigms, but it does not have a definitive complete and correct solution yet.
Specifically, in the field of exception handling, there have not been significant advances since the beginning of the millennium \cite{AllH03}, as later works have made minimal progress without finding any errors in Allen's proposal.
In this thesis, we show that the current treatment of exception handling constructs, such as \texttt{try-catch-finally} and \texttt{throw} is correct and complete only for some cases. We identify three distinct problems where the slices generated had lost correctness and completeness. We provide counter-examples to back up the problems, and generalize them to show the conditions necessary for them to surface.
An important contribution of our work has been the solutions proposed for each of the problems identified. Each exchanges a small amount of performance for an improvement in correctness or completeness. The solutions have been proposed specifically for Java's exception handling system, but are valid for almost any other programming language with a similar exception system (which can be seen in detail on section \ref{sec:exception-others}).
\section*{Future work}
\begin{itemize}
\item Implementation of the solutions proposed, so that they can be benchmarked against the previous state of the art, and used to build better program slicers. The implementation could be done in Java or another language with a similar exception-catch system. The solutions that improve correctness at the price of slice speed could be implemented as optional for the user to execute, as to avoid increasing the slicing software's temporal complexity.
\item Improved correctness for the \texttt{try-catch} statement. The solution proposed in chapter~\ref{cha:solution} does solve the lack of completeness in the treatment of \texttt{catch} statements, at the cost of including many more \texttt{catch} statements that are really necessary. This is not the most desirable outcome, but it can be improved by developing and implementing the measures suggested at the end of the solution: make the inclusion of the \texttt{catch} statements conditional upon two dependencies instead of one and represent \texttt{catch} statements multiple times, so that the method calls that throw errors may be selectively included.
\item Redefinition or specialization of control dependence: the system dependence graph is centred around the definitions of control and data dependence. The meaning of control dependence has slowly shifted as more kinds of statements have been included in program slicing, but its definition has remained almost constant for three decades. Unconditional jumps and \texttt{catch} statements introduce a new kind of control dependence which is not the traditional ``$b$ is control dependent on $a$ if the execution of $a$ affects whether or not $b$ executes'', but ``the \textit{presence} of $a$ affects whether or not $b$ executes''. This constitutes a substantial change that has not been reflected, and is the source of many problems when handling both unconditional jumps and \texttt{catch} statements.
\end{itemize}