475 lines
33 KiB
TeX
475 lines
33 KiB
TeX
% !TEX encoding = UTF-8
|
|
% !TEX spellcheck = en_US
|
|
% !TEX root = ../paper.tex
|
|
|
|
\chapter{Background}
|
|
\label{cha:background}
|
|
|
|
\section{Program slicing}
|
|
\textsl{Program slicing} \cite{Wei81,Sil12}\sergio{hay alguna razon para que \cite{Sil12} no este en la intro?, la unica cita alli es\cite{Wei81}. Propongo eliminar \cite{Sil12} por homogeneidad} is a debugging technique that
|
|
answers the question: ``which parts of a program affect a given statement and
|
|
set of variables?'' The statement and the variables are the basic input to create a slice
|
|
and are called the \textsl{slicing criterion}. The criterion can be more
|
|
complex, as different slicing techniques may require additional pieces of input.
|
|
The \textsl{slice} of a program is the list of statements from the original
|
|
program ---which constitutes a valid program--- whose execution will result in
|
|
the same values for the variables (selected in the slicing criterion).
|
|
There exist two fundamental dimensions along which the problem of slicing can be
|
|
proposed \cite{Sil12}:
|
|
|
|
\sergio{Mi propuesta es mover el concepto naive de aqui a la intro para que entiendan algo del ejemplo y aqui hacer referencia a la definicion anterior o introducir las dimensiones de slicing directamente con un pequenyo preambulo. Una fuerte razon para definirlo alli es que usamos todo el rato la palabra slice y de repente, despues de usarla un rato, la definimos.}
|
|
|
|
\begin{itemize}
|
|
\item \textsl{Static} or \textsl{dynamic}: slicing can be performed
|
|
statically or dynamically.
|
|
\textsl{Static slicing} \cite{Wei81} produces slices which consider all
|
|
possible executions of the program: the slice will be correct regardless of the input supplied.
|
|
In contrast, \textsl{dynamic slicing} \cite{KorL88} considers a single execution of the program, thus, limiting the slice to
|
|
the statements present in an execution log. The slicing criterion is
|
|
expanded to include a position in the log that corresponds to one
|
|
instance of the selected statement, making it much more specific. It may
|
|
help find a bug related to indeterministic behavior (such as a random
|
|
or pseudo-random number generator), but \sergio{, despite selecting the same slicing criterion, the slice }must be recomputed for each case\sergio{different input value/execution considered?}
|
|
being analyzed.
|
|
\item \textsl{Backward} or \textsl{forward}: \textsl{backward slicing}
|
|
\cite{Wei81} is generally more used \sergio{habra que decir lo que es antes de decir que se usa mas no? Cambiar el orden y reescribir esta frase. Decimos que es y luego que es el que generalmente se estudia o algo de eso}, because it looks at the statements
|
|
that affect the slicing criterion. In contrast, \textsl{forward slicing}
|
|
\cite{BerC85} computes the statements that are affected by the slicing
|
|
criterion. There also exists a mixed approach called \textsl{chopping}
|
|
\cite{JacR94}, which is used to find all statements that affect some variables in the slicing criterion and at the same time they are affected by some other variables in the slicing criterion.
|
|
\end{itemize}
|
|
|
|
Since the definition of program slicing\sergio{Since Weiser defined program slicing in 1981}, the most \deleted{extended form}\added{studied configuration?} of slicing has
|
|
been \textsl{static backward slicing}, which obtains the list of statements that
|
|
affect the value of a variable in a given statement, in all possible executions
|
|
of the program (i.e., for any input data).
|
|
\begin{definition}[Strong static backward slice \cite{Wei81,HorwitzRB88}]
|
|
\label{def:strong-slice}
|
|
\carlos{One of the citations is the correct one.}
|
|
Given a program $P$ and a slicing criterion $C = \langle s,v \rangle$, where
|
|
$s$ is a statement and $v$ is a set\sergio{los set no se representan con letras mayusculas?} of variables in $P$ (the variables may
|
|
or may not be used in $s$), $S$ is the \textsl{strong slice} of $P$ with
|
|
respect to $C$ if $S$ has\sergio{fulfils?} the following properties:
|
|
\begin{enumerate}
|
|
\item $S$ is an executable program.
|
|
\item $S \subseteq P$, or $S$ is the result of removing code\sergio{code o 0 or more statements?} from $P$.
|
|
\item For any input $I$, the values produced on each execution of $s$
|
|
for each of the variables in $v$ is the same when executing $S$ as
|
|
when executing $P$. \label{enum:exact-output}
|
|
\end{enumerate}
|
|
\end{definition}
|
|
\sergio{Esta definicion no obligaba tambien a acabar con el mismo error en caso de que la ejecucion no termine? Si es asi, plantearse poner algo al respecto.}
|
|
|
|
\begin{definition}[Weak static backward slice \cite{RepY89}]
|
|
\label{def:weak-slice}
|
|
\carlos{Check citation and improve ``formalization''?}
|
|
Given a program $P$ and a slicing criterion $C = \langle s,v \rangle$, where
|
|
$s$ is a statement and $v$ is a set of variables in $P$ (the variables may
|
|
or may not be used in $s$), $S$ is the \textsl{weak slice} of $P$ with
|
|
respect to $C$ if $S$ has\sergio{fulfils?} the following properties:
|
|
\begin{enumerate}
|
|
\item $S$ is an executable program.
|
|
\item $S \subseteq P$, or $S$ is the result of removing code from $P$. \sergio{idem}
|
|
\item For any input $I$, the values produced on each execution of $s$
|
|
for each of the variables in $v$ when executing $P$ is a prefix of
|
|
those produced while executing $S$ ---which means that the slice
|
|
may continue producing values, but the first values produced always
|
|
match up with all those produced by the original program.
|
|
\end{enumerate}
|
|
\end{definition}
|
|
|
|
\sergio{$\forall~i~\in~I, v\in~V~\rightarrow~seq(i,v,P)~Pref~seq(i,v,S)$ where $seq(i,a,A)$ representa la secuencia de valores obtenidos para $a$ al ejecutar el input $i$ en el programa $A$. $I$ es el conjunto de todos los inputs posibles para $P$. Por ahi irian los tiros creo yo.}
|
|
|
|
Both definitions (\ref{def:strong-slice} and~\ref{def:weak-slice}) are
|
|
used throughout the literature (see, e.g., \cite{pending}\carlos{Which citation? Most papers on exception slicing do not indicate or hint whether they use strong or weak.}\sergio{Josep?}), with some cases \deleted{favoring}\added{favouring} the first and some the
|
|
second. Though the definitions come from the corresponding citations, the naming
|
|
was first used in a control dependency analysis by Danicic~\cite{DanBHHKL11},
|
|
where slices that produce the same output as the original are named
|
|
\textsl{strong}, and those where the original is a prefix of the slice,
|
|
\textsl{weak}. Weak slicing tends to be preferred ---specially for debugging--- for two reasons: the algorithm can be simpler and avoid dealing with termination, and the slices can be smaller, narrowing the focus of the debugger. For some applications, \deleted{strong slices are preferred,} such as extracting a feature from a program, where there is a requirement that the resulting slice behave exactly like the original\added{, strong slices are preferred}. In this paper\sergio{??} we will indicate which kind of slice is produced with each new technique proposed. \sergio{Generamos alguna vez strong? Joder que cracks somos xD}
|
|
|
|
\begin{example}[Strong, weak and incorrect slices]
|
|
\carlos{The table is labeled execution logs of... but the execution log is a different thing.}
|
|
In table~\ref{tab:slice-weak} we can observe examples for the various
|
|
definitions. Each row shows the values \sergio{for a specific variable $v$ in the slicing criterion,} produced by \deleted{the}\added{a particular} execution of \deleted{a}\sergio{the original}
|
|
program or one of its slices.
|
|
The first \added{row stands for}\deleted{is} the original \added{program}, which computes $3!$.
|
|
Slice A's \deleted{execution log}\added{generated sequence of values} is identical to the original and therefore it is a strong slice.
|
|
Slice B is a weak slice: its execution correctly produces the same \added{sequence of }values as the original program, but it continues producing values after the original stops.
|
|
Slice C is incorrect, as the \added{generated sequence of} values differ\added{s} from the \added{sequence generated by the }original \added{program}.
|
|
\sergio{Taking a closer look, one could think that }Some data or control dependency has not been included in the slice and the program produce different results, in this case the slice computes Fibonacci numbers instead of factorials.\sergio{Esto no parece muy relevante, plantearse quitarlo para no liar con Fibonacci.}
|
|
\end{example}
|
|
|
|
\begin{table}
|
|
\centering
|
|
\label{tab:slice-weak}
|
|
\begin{tabular}{r | r | r | r | r | r }
|
|
\deleted{Iteration}\added{Evaluation Number} & \textbf{1} & \textbf{2} & \textbf{3} & \textbf{4} & \textbf{5} \\ \hline
|
|
Original & 1 & 2 & 6 & - & - \\ \hline
|
|
Slice A & 1 & 2 & 6 & - & - \\ \hline
|
|
Slice B & 1 & 2 & 6 & 24 & 120 \\ \hline
|
|
Slice C & 1 & 1 & 3 & 5 & 8 \\
|
|
\end{tabular}
|
|
\caption{\deleted{Execution logs of different slices and their original program.}\added{Sequence of values obtained for a certain variable of the original program and three different slices A, B and C for a particular input.}}
|
|
\end{table}
|
|
|
|
|
|
Program slicing is a language--agnostic tool\sergio{program slicing es tool o technique?}, but the original proposal by
|
|
Weiser~\cite{Wei81} covered a simple imperative programming language.
|
|
Since then, the literature has been expanded by dozens of authors, that have
|
|
described and implemented slicing for more complex structures, such as
|
|
uncontrolled control flow~\cite{HorwitzRB88}, global variables~\cite{???},
|
|
exception handling~\cite{AllH03}; and for other programming paradigms, such as
|
|
object--oriented languages~\cite{???} or functional languages~\cite{???}.
|
|
\carlos{Se pueden poner más, faltan las citas correspondientes.}\sergio{Guay, hay que buscarlas y ponerlas, la biblio la veo corta para todos los papers que hay, yo creo que cuando este todo deberia haber sobre 30 casi, si no mas.}
|
|
|
|
\subsection{The System Dependence Graph (SDG)}
|
|
|
|
There exist multiple approaches to compute a slice\sergio{esto me suena raro, yo diria program representations o data structures that allow the use of program slicing techniques o algo asi, debatirlo} from a given program and
|
|
slicing criterion, but the most efficient and broadly used data structure is the System
|
|
Dependence Graph (SDG), first introduced by Horwitz, Reps and
|
|
Blinkey \sergio{in 1988}\sergio{Todos los autores o los citamos con et al.? lo digo por seguir la misma regla durante todo el document}~\cite{HorwitzRB88}. It is computed from the program's statements\sergio{source code}, and
|
|
once built, a slicing criterion is chosen, the graph \added{is} traversed using a specific
|
|
algorithm, and the slice \added{is} obtained. Its efficiency resides in the fact that\added{,} for
|
|
multiple slices \deleted{that share}\added{calculated for} the same program, the graph \deleted{must only be built}\added{generation process is only performed} once.
|
|
On top of that, building the graph has a complexity of $\mathcal{O}(n^2)$ \carlos{uso $\mathcal{O}$ o $O$?}\sergio{Josep?} with
|
|
respect to the number of statements in \deleted{a}\added{the} program, but the traversal is linear
|
|
with respect to the number of nodes in the graph (each corresponding to a
|
|
statement) \sergio{footnote?}.
|
|
|
|
The SDG is a directed graph, and as such it has vertices or nodes, each
|
|
representing an \deleted{instruction}\added{statement} in the program ---barring some auxiliary nodes
|
|
introduced by some approaches--- and directed edges, which represent the
|
|
dependencies among nodes. Those edges represent various\sergio{several} kinds of dependencies
|
|
---control, data, calls, parameter passing, summary--- which will be defined\sergio{further explained?} in
|
|
section~\ref{sec:first-def-sdg}.
|
|
|
|
To create the SDG, first \deleted{a}\added{the corresponding} \textsl{control flow graph} (CFG) is built for each method
|
|
in the program, then\added{,} its \added{associated }control and data dependencies are computed, resulting
|
|
in \added{a new graph representation known as }the \textsl{program dependence graph} (PDG)\sergio{cita??}. Finally, all the graphs from every
|
|
method are joined \added{by the appearance of a new kind of inter-procedural arcs, the argument-in argument-out arcs that link function definitions with function calls, obtaining}\deleted{into} the \added{final} SDG. This process will be explained at greater
|
|
lengths in section~\ref{sec:first-def-sdg}.
|
|
%TODO: marked for removal --- this process is repeated later in ref{sec:first-deg-sdg}
|
|
%\begin{description}
|
|
%\item[CFG] The control flow graph is the representation of the control
|
|
%dependencies in a method of a program. Every statement has an edge from
|
|
%itself to every statement that can immediately follow. This means that
|
|
%most will only have one outgoing edge, and conditional jumps and loops
|
|
%will have two. The graph starts in a ``Begin'' or ``Start'' node, and
|
|
%ends in an ``End'' node, to which the last statement and all return
|
|
%statements are connected. It is created directly from the source code,
|
|
%without any need for data dependency analysis.
|
|
%\item[PDG] The program dependence graph is the result of restructuring and
|
|
%adding data dependencies to a CFG. All statements are placed below and
|
|
%connected to a ``Begin'' node, except those which are inside a loop or
|
|
%conditional block. Then data dependencies are added (red or dashed
|
|
%edges), adding an edge between two nodes if there is a data dependency.
|
|
%\item[SDG] Finally, the system dependence graph is the interconnection of
|
|
%each method's PDG. When a call is made, the input arguments are passed
|
|
%to subnodes of the call, and the result is obtained in another subnode.
|
|
%There is an edge from the call to the beginning of the corresponding
|
|
%method, and an extra type of edge exists: \textsl{summary edges}, which
|
|
%summarize the data dependencies between input and output variables.
|
|
%\end{description}
|
|
An example \added{of how an initial CFG is augmented and enhanced with all mentioned dependencies obtaining the corresponding PDG and the final SDG} is provided in figure~\ref{fig:basic-graphs}, where a \added{the process is illustrated for a} simple
|
|
multiplication program\deleted{ is converted to CFG, then PDG and finally SDG}. For
|
|
simplicity, only the CFG and PDG of \texttt{main} are omitted\sergio{no entiendo esto de main. Donde esta main?}. Control
|
|
dependencies are \added{represented with }black \added{arcs}, data dependencies \added{with} red \added{arcs}, and summary edges \added{are depicted with }blue \added{arcs}.
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\begin{minipage}{0.4\linewidth}
|
|
\begin{lstlisting}
|
|
int multiply(int x, int y) {
|
|
int result = 0;
|
|
while (x > 0) {
|
|
result += y;
|
|
x--;
|
|
}
|
|
System.out.println(result);
|
|
return result;
|
|
}
|
|
\end{lstlisting}
|
|
\end{minipage}
|
|
\begin{minipage}{0.59\linewidth}
|
|
\includegraphics[width=\linewidth]{img/multiplycfg}
|
|
\end{minipage}
|
|
\includegraphics[width=\linewidth]{img/multiplypdg}
|
|
\includegraphics[width=\linewidth]{img/multiplysdg}
|
|
\caption{A simple multiplication program, its CFG, PDG and SDG}
|
|
\label{fig:basic-graphs}
|
|
\end{figure}
|
|
\sergio{nose si vale la pena poner la Figure~\ref{fig:basic-graphs} aqui, no hemos contado aun como se genera, sino que se genera y se supone que se cuenta mas adelante, tal vez sea mas util hacer referencia forward solo y no poner esta figura aqui, sino mas adelante. Plantearselo}
|
|
|
|
\subsection{Metrics}
|
|
\sergio{Metrics o slicing indicators/features? }
|
|
|
|
|
|
There are four relevant metrics considered when evaluating a slicing algorithm:
|
|
\sergio{Se me hace muy escueto esto, yo meteria algo de bullshit como dice Tama.}
|
|
|
|
\sergio{PROPOSAL:}
|
|
|
|
\sergio{In the area of program slicing, there are many different slicing techniques and tools implementing them. This fact has created the necessity to classify them by defining a set of different metrics. These metrics are commonly associated to some features of the generated slices. In the following, we list the most relevant metrics considered when evaluating a program slice:}
|
|
|
|
\begin{description}
|
|
\item[Completeness.] The solution includes all the statements that affect
|
|
the slicing criterion. This is the most important feature, and almost all
|
|
publications achieve at least completeness. Trivial completeness is
|
|
easily achievable, as simple as including the whole program in the
|
|
slice.
|
|
\item[Correctness.] The solution excludes all statements that do not affect
|
|
the slicing criterion. Most solutions are complete, but the degree of correctness is
|
|
what sets them apart, as solutions that are more correct will produce smaller slices, which will execute fewer instructions to compute the same values, decreasing the executing time and complexity.
|
|
\item[Features covered.] Which features or language a slicing algorithm
|
|
covers. Different approaches to slicing cover different programming
|
|
languages and even paradigms. There are slicing techniques (published or
|
|
commercially available) for most popular programming languages, from C++
|
|
to Erlang. Some slicing techniques only cover a subset of the targeted
|
|
language, and as such are less useful for commercial applications, but
|
|
can be a stepping stone in the betterment of the field.\sergio{Tambien estan las valen para todos los lenguajes, ORBS entraria en ese caso no Josep?}
|
|
\item[Speed.] Speed of graph generation and slice creation. As previously
|
|
stated, slicing is a two-step process: building a graph and traversing it \sergio{esta frase hace parece que hacer slicing es dibujo libre... darle algo de importancia hablando de traducir el codigo a una representacion en forma de grafo con un estructura de datos compleja bla bla bla...}.
|
|
The traversal is a linear two--pass analysis of a graph in most proposals, with small variations.
|
|
Graph generation tends to be a longer process, but it is not as
|
|
relevant, because it is only done once (per program being analyzed), making this the least important metric. \sergio{Puedes anyadir que aunque la metrica del proceso de generacion no se suele tener muy en cuenta, esta existe porque es donde hay que hacer el analisis mas costoso sobre el programa y tal... relleno a saco! Que parece que no tiene ni merito generar el grafo :(}
|
|
Only proposals that deviate from the aforementioned schema of building a graph and traversing it show a wider variation in speed.
|
|
\end{description}
|
|
|
|
\subsection{Program slicing as a debugging technique}
|
|
|
|
\sergio{Soy pesado pero esto se me vuelve a hacer muy corto :/. Retoco esto un poco}
|
|
|
|
\added{As stated before, there are many uses for program slicing: program specialization, software maintenance, code obfuscation... but there is no doubt that p}\deleted{P}rogram slicing is first and foremost a debugging technique\added{.} \deleted{, having e}\added{E}ach\deleted{variation}\added{configuration of different dimensions serves} a different purpose:
|
|
|
|
|
|
\begin{description}
|
|
\item[Backward static.] Used to obtain the lines that affect a statement,
|
|
normally used on a line which outputs an incorrect value, to narrow\sergio{track?} down
|
|
the source of the bug.
|
|
\item[Forward static.] Used to obtain the lines affected by a statement,
|
|
used to identify dead code, to check the effects a line has on the rest
|
|
of the program.
|
|
\item[Chopping static.] Obtains both the statements affected by and the
|
|
statements that affect the selected statement.
|
|
\item[Dynamic.] Can be combined with any of the previous variations, and
|
|
limits the slice to an execution log, only including statements that
|
|
have run in a specific execution. The slice produced is much smaller and
|
|
useful.
|
|
\item[Quasi--static.] \added{In this slicing method s}\deleted{S}ome input values are given, and some are left
|
|
unspecified: the result is a slice between the small dynamic slice and
|
|
the general but bigger static slice. It can be specially useful when
|
|
debugging a set of function calls which have a specific static input for
|
|
some parameters, and variable input for others.
|
|
\item[Simultaneous.] Similar to dynamic slicing, but considers multiple
|
|
executions instead of only one. Similarly to quasy--static slicing, it
|
|
can offer a slightly bigger slice while keeping the scope focused on the
|
|
source of the bug.
|
|
\item
|
|
\carlos{añadir más quizá???}
|
|
\sergio{a mi me parecen suficientes, puedes decir una frasecita de 2 o 3 lineas diciendo que hay mas y algun uso de alguno de los otros que queden asi a lo general, pero yo los veo suficientes.}
|
|
\end{description}
|
|
|
|
\section{Exception handling in Java}
|
|
\label{sec:intro-exception}
|
|
|
|
Exception handling is common in most modern programming languages. \added{Exception handling generally consists in a set of statements that modify the normal execution flow noticing the existence of an abnormal program behaviour (controlled or not), and can be handled manually by the programmer or automatically by the system, depending on the programming language. In our work we focus on the Java programming language, so in the following, we describe the elements that Java uses to represent and handle exceptions:} \deleted{In Java, it
|
|
consists of the following elements:}
|
|
\begin{description}
|
|
\item[Throwable.] An interface that encompasses all the exceptions or errors
|
|
that may be thrown. Its child classes are \texttt{Error} for internal errors in the Java Virtual Machine and \texttt{Exception} for normal errors.
|
|
Exceptions can be classified as \textsl{unchecked}
|
|
(those that extend \texttt{RuntimeException}\sergio{se sale esto de la linea por el texttt} or \texttt{Error}) and
|
|
\textsl{checked} (all others, may inherit from \texttt{Throwable}, but typically they do so from \texttt{Exception}). The first kind may be thrown anywhere without warning, whereas
|
|
the second, if thrown, must be either caught in the same method or declared in the method header.
|
|
\item[throws.] A statement that activates an exception, altering the normal
|
|
control-flow of the method. If the statement is inside a \textsl{try}
|
|
block with a \textsl{catch} clause for its type or any supertype, the
|
|
control flow will continue in the first statement of such clause.
|
|
Otherwise, the method is exited and the check performed again, until
|
|
either the exception is caught or the last method in the stack
|
|
(\textsl{main}) is popped, and the execution of the program ends
|
|
abruptly.
|
|
\item[try.] This statement is followed by a block of statements and by one
|
|
or more \textsl{catch} clauses. All exceptions thrown in the statements
|
|
contained or any methods called will be processed by the list of
|
|
catches. Optionally, after the \textsl{catch} clauses a \textsl{finally}
|
|
block may appear.
|
|
\item[catch.] Contains two elements: a variable declaration (the type must
|
|
be an exception \sergio{exception o exception type?}) and a block of statements to be executed when an
|
|
exception of the corresponding type (or a subtype) is thrown.
|
|
\textsl{catch} clauses are processed sequentially, and if any matches
|
|
the type of the thrown exception, its block is executed, and the rest
|
|
are ignored. Variable declarations may be of multiple types
|
|
\texttt{(T1|T2 exc)}, when two unrelated types of exception must be
|
|
caught and the same code executed for both. When there is an inheritance
|
|
relationship, the parent suffices.\footnotemark
|
|
\item[finally.] Contains a block of statements that will always be executed
|
|
if the \textsl{try} is entered. It is used to tidy up, for example
|
|
closing I/O streams. The \textsl{finally} can be reached in two ways:
|
|
with an exception pending (thrown in \textsl{try} and not captured by
|
|
any \textsl{catch} or thrown inside a \textsl{catch}) or without it
|
|
(when the \textsl{try} or \textsl{catch} block end successfully). After
|
|
the last instruction of the block is executed, if there is an exception
|
|
pending, control will be passed to the corresponding \textsl{catch} or
|
|
the program will end. Otherwise, the execution continues in the next
|
|
statement after the \textsl{try-catch-finally} block.
|
|
\end{description}
|
|
\sergio{Me han molao las explicaciones, se entiende muy bien como funciona Java, parece que sea hasta facil de usar :D}
|
|
|
|
\footnotetext{Introduced in Java 7, see \url{https://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html} for more details.}
|
|
|
|
\subsection{Exception handling in other programming languages}
|
|
|
|
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
|
|
popular object--oriented programs feature some kind of error system, normally
|
|
very similar to Java's exceptions. In this section, we will perform a small
|
|
survey of the error-handling techniques used on the most popular programming
|
|
languages. The language list has been extracted from a survey performed by the
|
|
programming Q\&A website Stack
|
|
Overflow\footnote{\url{https://stackoverflow.com}}. The survey contains a
|
|
question about the technologies used by professional developers in their work,
|
|
and from that list we have extracted those languages with more than $5\%$ usage
|
|
in the industry. Table~\ref{tab:popular-languages} shows the list and its
|
|
source. Except Bash, Assembly, VBA, C and G,\sergio{Bash y companyia no tienen mecanismo de exception handling? o no se parece al de Java? No queda claro en esta frase} the rest of the languages shown
|
|
feature an exception system similar to the one appearing in Java.
|
|
|
|
\begin{table}
|
|
\begin{minipage}{0.6\linewidth}
|
|
\centering
|
|
\begin{tabular}{r | r }
|
|
\textbf{Language} & $\%$ usage \\ \hline
|
|
JavaScript & 69.7 \\ \hline
|
|
HTML/CSS & 63.1 \\ \hline
|
|
SQL & 56.5 \\ \hline
|
|
Python & 39.4 \\ \hline
|
|
Java & 39.2 \\ \hline
|
|
Bash/Shell/PowerShell & 37.9 \\ \hline
|
|
C\# & 31.9 \\ \hline
|
|
PHP & 25.8 \\ \hline
|
|
TypeScript & 23.5 \\ \hline
|
|
C++ & 20.4 \\ \hline
|
|
\end{tabular}
|
|
\end{minipage}
|
|
\begin{minipage}{0.39\linewidth}
|
|
\begin{tabular}{r | r }
|
|
\textbf{Language} & $\%$ usage \\ \hline
|
|
C & 17.3 \\ \hline
|
|
Ruby & 8.9 \\ \hline
|
|
Go & 8.8 \\ \hline
|
|
Swift & 6.8 \\ \hline
|
|
Kotlin & 6.6 \\ \hline
|
|
R & 5.6 \\ \hline
|
|
VBA & 5.5 \\ \hline
|
|
Objective-C & 5.2 \\ \hline
|
|
Assembly & 5.0 \\ \hline
|
|
\end{tabular}
|
|
\end{minipage}
|
|
% The caption has a weird structure due to the fact that there's a footnote
|
|
% inside of it.
|
|
\caption[Commonly used programming languages]{The most commonly used
|
|
programming languages by professional developers\protect\footnotemark}
|
|
\label{tab:popular-languages}
|
|
\end{table}
|
|
|
|
\footnotetext{Data from \url{https://insights.stackoverflow.com/survey/2019/\#technology-\_-programming-scripting-and-markup-languages}}
|
|
|
|
The exception systems that are similar to Java are mostly all the same,
|
|
featuring a \texttt{throw} statement (\texttt{raise} in Python), try-catching
|
|
structure and most include a finally block that may be appended to try blocks.
|
|
The difference resides in the value passed by the exception, which in languages
|
|
that feature inheritance it is a class descending from a generic error or
|
|
exception, and in languages without it\sergio{este ``it" se refiere a inheritance? pon algun objeto y elimina algun it porque hay muchos y me lian xD}, it is an arbitrary value (e.g.
|
|
JavaScript, TypeScript). In object--oriented programming, the filtering is
|
|
performed by comparing if the exception is a subtype of the exception being
|
|
caught (Java, C++, C\#, PowerShell\footnotemark, etc.); and in languages with
|
|
arbitrary exception values, a boolean condition is specified, and the first
|
|
catch block that fulfills its condition is activated, in following\sergio{in following o following?} a pattern
|
|
similar to that of \texttt{switch} statements (e.g. JavaScript). In both cases
|
|
there exists a way to indicate that all exceptions should be caught, regardless
|
|
of type and content.
|
|
|
|
\footnotetext{Only since version 2.0, released with Windows 7.}
|
|
|
|
On the other hand, in \deleted{the other languages } \sergio{``the other languages" es muy vago}\added{those languages that do not offer explicit exception handling mechanisms,} \deleted{there exist a variety of systems that emulate or replace exception handling:}\added{this feature is covered by a variety of systems that emulate or replace their behaviour:}
|
|
|
|
\begin{description} % bash, vba, C and Go exceptions explained
|
|
\item[Bash.] The popular Bourne Again SHell features no exception system, apart
|
|
from the user's ability to parse the return code from the last statement
|
|
executed. Traps can also be used to capture erroneous states and tidy up all
|
|
files and environment variables before exiting the program. Traps allow the
|
|
programmer to react to a user or system--sent signal, or an exit run from
|
|
within the Bash environment. When a trap is activated, its code run, and the
|
|
signal does not proceed and stop the program. This does not replace a fully
|
|
featured exception system, but \texttt{bash} programs tend to be short, with programmers preferring the efficiency of C or the commodities of
|
|
other high--level languages when the task requires it.
|
|
\item[VBA.] Visual Basic for Applications is a scripting programming language
|
|
based on Visual Basic that is integrated into Microsoft Office to automate
|
|
small tasks, such as generating documents from templates, making advanced
|
|
computations that are impossible or slower with spreadsheet functions, etc.
|
|
The only error--correcting system it has is the directive \texttt{On Error
|
|
$x$}, where $x$ can be 0 ---lets the error crash the program---,
|
|
\texttt{Next} ---continues the execution as if nothing had happened--- or a
|
|
label in the program ---the execution jumps to the label in case of
|
|
error. The directive can be set and reset multiple times, therefore creating
|
|
artificial \texttt{try-catch} blocks, but there is no possibility of
|
|
attaching a value to the error, lowering its usefulness.
|
|
\item[C.] In C, errors can also be controlled via return values, but some
|
|
instructions featured in it can be used to create a simple exception system.
|
|
\texttt{setjmp} and \texttt{longjmp} are two instructions which set up and
|
|
perform inter--function jumps. The first makes a snapshot of the call stack
|
|
in a buffer, and the second returns to the position where the buffer was
|
|
safe, destroying the current state of the stack and replacing it with the
|
|
snapshot. Then, the execution continues from the evaluation of
|
|
\texttt{setjmp}, which returns the second argument passed to
|
|
\texttt{longjmp}.
|
|
\begin{example}[User-built exception system in C] \ \\
|
|
\label{fig:exceptions-c}
|
|
\begin{minipage}{0.5\linewidth}
|
|
\begin{lstlisting}[language=C]
|
|
int main() {
|
|
if (!setjmp(ref)) {
|
|
res = safe_sqrt(x, ref);
|
|
} else {
|
|
// Handle error
|
|
printf /* ... */
|
|
}
|
|
}
|
|
\end{lstlisting}
|
|
\end{minipage}
|
|
\begin{minipage}{0.49\linewidth}
|
|
\begin{lstlisting}[language=C]
|
|
double safe_sqrt(double x, int ref) {
|
|
if (x < 0)
|
|
longjmp(ref, 1);
|
|
return /* ... */;
|
|
}
|
|
\end{lstlisting}
|
|
\end{minipage}
|
|
In the \texttt{main} function, line 2 will be executed twice: first when
|
|
it is normally reached ---returning 0 and continuing in line 3--- and the second when line 3 in
|
|
\texttt{safe\_sqrt} is run, returning the second argument of \texttt{longjmp},
|
|
and therefore entering the else block in the \texttt{main} method.
|
|
\end{example}
|
|
\item[Go.] The programming language Go is the odd one out in this section, being a
|
|
modern programming language without exceptions, though it is an intentional
|
|
design decision made by its authors\footnotemark. The argument made was that
|
|
exception handling systems introduce abnormal control--flow and complicate
|
|
code analysis and clean code generation, as it is not clear the paths that
|
|
the code may follow. Instead, Go allows functions to return multiple values,
|
|
with the second value typically associated to an error type. The error is
|
|
checked before the value, and acted upon. Additionally, Go also features a
|
|
simple panic system, with the functions \texttt{panic} ---throws an
|
|
exception with a value associated---, \texttt{defer} ---runs after the
|
|
function has ended or when a \texttt{panic} has been activated--- and
|
|
\texttt{recover} ---stops the panic state and retrieves its value. The
|
|
\texttt{defer} statement doubles as catch and finally, and multiple
|
|
instances can be accumulated. When appropriate, they will run in LIFO\deleted{order}
|
|
(Last In--First Out) \added{order}.
|
|
\item[Assembly.] Assembly is a representation of machine code, and each computer architecture has its own instruction set, which makes an analysis impossible. In general, though, no unified exception handling is provided. \carlos{complete with more info on kinds of error handling at the processor level or is this out of scope???}\sergio{Si metes una explicacion asi breve que se entienda bien, si va a ser muy tecnico yo pararia aqui. Diria que las excepciones se manejan a nivel de procesador o lo que sea asi por encima y matizao}
|
|
\end{description}
|
|
|
|
\footnotetext{For more details on Go's design choices, see \url{https://golang.org/doc/faq\#exceptions}. \carlos{Possible transformation to citation???}\sergio{No creo que nos vaya a hacer falta. Con el state of the art y la intro tendremos bastantes.}}
|
|
|
|
% vim: set noexpandtab:tabstop=2:shiftwidth=2:softtabstop=2:wrap
|