scispace - formally typeset

Proceedings ArticleDOI

A semantics for execution levels with exceptions

21 Mar 2011-pp 7-11

TL;DR: This paper proposes a semantics for an aspect-oriented language with execution levels and an exception handling mechanism that solves the exception conflation problem and illustrates the benefits of the proposal with a representative set of examples.

AbstractAspect-oriented languages are usually formulated as an extension to existing languages, without paying any special attention to the underlying exception handling mechanisms. Consequently, aspect exceptions and handlers are no different than base exceptions and handlers. Conflation between aspect and base exceptions and handlers may inadvertently trigger execution of unintended handlers, changing the expected program behavior: aspect exceptions are accidentally caught by base handlers or vice-versa. Programmers cannot state the desired interaction between aspect and base exceptions and handlers. Specific instances of this issue have been identified by others researchers. We distill the essence of the problem and designate it as the exception conflation problem. Consequently, we propose a semantics for an aspect-oriented language with execution levels and an exception handling mechanism that solves the exception conflation problem. By default, the language ensures there is no interaction between base and aspect exceptions and handlers, and provides level-shifting operators to flexibly specify interaction between them when required. We illustrate the benefits of our proposal with a representative set of examples

Topics: Exception handling (53%)

Summary (2 min read)

1. INTRODUCTION

  • Aspect-oriented languages aim at modularizing crosscutting concerns.
  • Subtle interactions between aspect and base exceptions and handlers may arise.
  • A Logging aspect advises around the getConfiguration method.

2. EXECUTION LEVELS IN A NUTSHELL

  • The authors first summarize the proposal of execution levels.
  • An advice is a piece of code, and therefore its execution also produces join points.
  • In higher-order aspect languages like AspectScript [12] and others, all pointcuts and advice are standard functions, whose application and evaluation produce join points as well.
  • This of course opens the door to infinite regression and unwanted interference between aspects.
  • By separating execution into levels, unwanted interactions between aspects are avoided.

3. SEMANTICS

  • Which the authors then extend with exception handling.
  • The complete semantics for the original language and the exception handling extensions are defined using PLT Redex, a domain-specific language for specifying reduction semantics [5].
  • The complete semantics implementation, along an executable test suite, and examples shown in Section 4 are available at http://pleiad.cl/research/scope.

3.1 Original Semantics

  • Tanter’s proposal defines a simple Scheme-like language with higher-order aspects, and execution levels as described in Section 2.
  • The user-visible expressions are values, identifiers, if statements, multi-arity function application, and aspect deployment.
  • A reduction relation → describes the operational semantics of their language using reduction steps.
  • Aspect weaving ensures that pointcuts and advices are evaluated with up, and that the last proceed in the chain is evaluated with down [10].
  • Rule APPSHIFT shows that when a level-capturing function is applied, it embeds the reduction of the application in an in-shift expression.

3.2 Exception Handling Semantics

  • The authors introduce a standard exception handling mechanism [9], using the extensions shown in Figure 3.
  • Certainly, there are situations where interaction is desired.
  • The raise expression signals an exception that embeds a value to carry information to the handler.
  • For simplicity the authors omit the propagation rules here.
  • They are present in the downloadable complete semantics specification.

4. APPLICATIONS

  • For all the examples the authors assume that the pointcut associated to the advice matches any function call.
  • Thus, the base expression reduces to (raise0 #f).
  • When the call to proceed raises the exception bound at level 0, the handler catches it because they are both bound to the same level.
  • The examples show the key interactions between aspect and base handlers and exceptions, and the mechanism that their semantics provide to the programmer to specify the desired interaction.

Did you find this useful? Give us your feedback

...read more

Content maybe subject to copyright    Report

A Semantics for Execution Levels with Exceptions
Ismael Figueroa
PLEIAD Laboratory
Computer Science Department (DCC)
University of Chile Santiago, Chile
ifiguero@dcc.uchile.cl
Éric Tanter
PLEIAD Laboratory
Computer Science Department (DCC)
University of Chile Santiago, Chile
etanter@dcc.uchile.cl
ABSTRACT
Aspect-oriented languages are usually formulated as an extension
to existing languages, without paying any special attention to the
underlying exception handling mechanisms. Consequently, aspect
exceptions and handlers are no different than base exceptions and
handlers. Conflation between aspect and base exceptions and han-
dlers may inadvertently trigger execution of unintended handlers,
changing the expected program behavior: aspect exceptions are
accidentally caught by base handlers or vice-versa. Programmers
cannot state the desired interaction between aspect and base excep-
tions and handlers. Specific instances of this issue have been identi-
fied by others researchers. We distill the essence of the problem and
designate it as the exception conflation problem. Consequently, we
propose a semantics for an aspect-oriented language with execution
levels and an exception handling mechanism that solves the excep-
tion conflation problem. By default, the language ensures there is
no interaction between base and aspect exceptions and handlers,
and provides level-shifting operators to flexibly specify interaction
between them when required. We illustrate the benefits of our pro-
posal with a representative set of examples.
Categories and Subject Descriptors: D.3.3 [Programming Lan-
guages]: Language Constructs and Features
General Terms: Languages, Design
Keywords: Exception handling, aspect-oriented programming, ex-
ception conflation, execution levels
1. INTRODUCTION
Aspect-oriented languages aim at modularizing crosscutting con-
cerns. Well-known aspect-oriented languages, like AspectJ, define
crosscutting behavior using pointcuts and advices: join points are
interesting events raised during program execution, pointcuts are
predicates over join points to determine the application of advice.
Advice is code that executes after, before or instead of the compu-
Funded by a CONICYT Doctoral Scolarship.
Partially funded by FONDECYT Project 1110051.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
FOAL’11, March 21, 2011, Pernambuco, Brazil.
Copyright 2011 ACM 978-1-4503-0644-7/11/03 ...$10.00.
1 class A {
2 public void foo() {
3 Integer configValue;
4 try { configValue = getConfiguration();
5 } catch(Exception ex) { configValue = DEFAULT}}
6 }
7 aspect Logging {
8 Object around() : call(Integer getConfiguration()) {
9 logger.append("Calling getConfiguration’’); // FileNotFoundException
10 return proceed();}
11 }
Listing 1: Base handler catches aspect exception
tation represented by a join point. An aspect is an abstraction to
specify crosscutting behavior.
Exceptions are a mechanism to deal with abnormal states of
computation in a uniform and modular way by a lexical separa-
tion between normal and error handling code. When an abnormal
situation ocurrs, an exception is thrown and then propagates dy-
namically through the call stack in search for a suitable handler. A
handler is a special code section which executes receiving an ex-
ception as parameter. If a handler is not found the exception is
uncaught, usually aborting program execution.
Subtle interactions between aspect and base exceptions and han-
dlers may arise. Aspect exceptions may be inadvertently handled
by base handlers. Conversely, base exceptions may be caught by as-
pect handlers. For example, consider the AspectJ code of Listing 1.
The foo method calls getConfiguration to set configValue. In case of
failure, a default value is used. A Logging aspect advises around
the getConfiguration method. If the logger object cannot find the
log file it shall fail and throw a FileNotFoundException, which is
caught by the base handler. Thus, the default value is used because
the aspect failed, even in cases where getConfiguration would have
returned normally.
This situation arises because the exception handling mechanism
merges aspect and base handlers and exceptions in a flat structure.
We call this situation the exception conflation problem. The ex-
ception conflation problem is a generalization of the Late Binding
Handler Pattern of Coelho et al., which is described as: “...happens
when an aspect is created to handle an exception, but the aspect in-
tercepts a point in the program execution where the exception to be
caught was already caught by a handler in the method call chain
that connects the exception signaler to the aspect handler” [4].
In this paper we propose a semantics for an aspect-oriented lan-
guage that discriminates aspect and base exceptions using execu-
tion levels, extending Tanter’s original proposal [10]. The language
ensures that by default there is no interference between aspect and
base exceptions and provides level-shifting operators to flexibly

pc( )
..move(..)..
call
pcexec
..setX(..)..
call
ctx
adv(..ctx..)
advexec
..before.. (proceed p) ..after..
Figure 1: Execution levels in action: pointcut and advice are
evaluated at level 1, proceed goes back to level 0 (from [10]).
specify their interactions when required. We illustrate the bene-
fits of our proposal showing representative examples of interaction
between aspect and base exceptions and handlers.
The rest of this paper is structured as follows: Section 2 recalls
the notion of execution levels, Section 3 defines the semantics of
the proposed language, Section 4 shows the applications of this
language to exception handling issues, Section 5 discusses related
work, and Section 6 concludes.
2. EXECUTION LEVELS IN A NUTSHELL
We first summarize the proposal of execution levels. An aspect
observes the execution of a program through its pointcuts, and af-
fects it with its advice. An advice is a piece of code, and there-
fore its execution also produces join points. Similarly, pointcuts
as well can produce join points. For instance, in AspectJ, one can
use an if pointcut designator to specify an arbitrary Java expres-
sion that ought to be true for the pointcut to match. The evaluation
of this expression is a computation that produces join points. In
higher-order aspect languages like AspectScript [12] and others,
all pointcuts and advice are standard functions, whose application
and evaluation produce join points as well.
The fact that aspectual computation produces join points raises
the crucial issue of the visibility of these join points. In most lan-
guages, aspectual computation is visible to all aspects—including
themselves. This of course opens the door to infinite regression
and unwanted interference between aspects. These issues are typ-
ically addressed with ad-hoc checks (e.g. using !within and cflow
checks in AspectJ) or primitive mechanisms (like AspectScheme’s
app/prim). However, all these approaches eventually fall short for
they fail to address the fundamental problem, which is that of con-
flating levels that ought to be kept separate [2].
In order to address the above issue, Tanter proposed execution
levels for AOP [10]. A program computation is structured in lev-
els. Computation happening at level 0 produces join points observ-
able at level 1 only. Aspects are deployed at a particular level, and
observe only join points at that level. This means that an aspect
deployed at level 1 only observes join points produced by level-0
computation. In turn, the computation of an aspect (i.e. the eval-
uation of its pointcuts and advice) is reified as join points visible
at the level immediately above: therefore, the activity of an aspect
standing at level 1 produces join points at level 2.
An aspect that acts around a join point can invoke the original
computation. For instance, in AspectJ, this is done by invoking
proceed in the advice body. The original computation ought to run
at the same level at which it originated!
1
In order to address this
1
This issue is precisely why using control flow checks in AspectJ
in order to discriminate advice computation is actually flawed.
See [10] for more details.
issue, it is important to remember that when several aspects match
the same join point, the corresponding advice are chained, such
that calling proceed in advice k triggers advice k +1. Therefore,
the semantics of execution levels guarantees that the last call to
proceed in a chain of advice triggers the original computation at
the lower original level.
This is shown in Figure 1. A call to a move method in the pro-
gram produces a call join point (at level 1), against which a point-
cut pc is evaluated. The evaluation of pc produces join points at
level 2. If the pointcut matches, it passes context information ctx
to the advice. Advice execution produces join points at level 2,
except for proceed: control goes back to level 0 to perform the
original computation, then goes back to level 1 for the after part of
the advice.
Level-shifting operators. The default semantics of execution levels
treats aspects as a meta-level computation. However, in some cases,
advice execution should be visible to aspects that observe base level
execution. To reconcile both approaches, Tanter proposed explicit
level-shifting operators: up and down. Shifting an expression us-
ing up or down moves its computation one level above or below, af-
fecting the visibility of its join points. With these operators the pro-
grammer can specify the level at which computation is performed,
according to specific needs.
Level-capturing functions. Certain applications require delayed
execution of operations, for example: a prioritized command queue
may accumulate a number of requests before executing them or a
task scheduler may execute certain tasks at determined time inter-
vals. In these cases, the operations may not be performed in the
same execution thread in which they were declared, so the control
flow checks to avoid regression problems fail. In addition, the exe-
cution may be performed at a different level than when it was post-
poned. To address this issue Tanter introduces level-capturing func-
tions that keep track of the level at which they were declared. When
a level-capturing function is executed, the execution level shifts to
the function-captured level, and then shifts back afterwards.
By separating execution into levels, unwanted interactions be-
tween aspects are avoided. For instance, it becomes possible to
reuse off-the-shelf dynamic analysis aspects and apply them to a
given program, and/or aspects, with consistent semantics [11].
3. SEMANTICS
In this section we first recall the core syntax and semantics of
Tanter’s original proposal [10], which we then extend with excep-
tion handling. The complete semantics for the original language
and the exception handling extensions are defined using PLT Re-
dex, a domain-specific language for specifying reduction seman-
tics [5]. The complete semantics implementation, along an exe-
cutable test suite, and examples shown in Section 4 are available at
http://pleiad.cl/research/scope.
3.1 Original Semantics
Tanter’s proposal defines a simple Scheme-like language with
higher-order aspects, and execution levels as described in Section 2.
The language has booleans, numbers and lists, primitives functions
to operate on these, and an internal app/prim operator to apply
functions without generating join points [10]. Figure 2 shows the
core syntax and reduction rules of the language. The user-visible
expressions are values, identifiers, if statements, multi-arity func-
tion application, and aspect deployment. These are shown in bold
font. The other expressions shown in the figure are related to level-
shifting operations, and are shown with typewriter font.
A reduction relation describes the operational semantics of

Value v ::= (λ(x ···) e) | (λ
(x ···) e)
| n | #t | #f
| (list v ···) | prim | unspecified
prim ::= deploy | list | cons | car | cdr
| empty? | eq? | + ||...
Expr e ::= v | x | (ee···) | (if eee)
| (up e) | (down e)
| (in-up e) | (in-down e)
| (in-shift(e))
| (app/prim ee···)
v V , the set of values
n N , the set of numbers
list L , the set of lists
x X , the set of variable names
e E , the set of expressions
EvalC tx E ::= [ ] | (v ··· Ee···) | (if Eee)
| (up E) | (down E)
| (in-up E) | (in-down E)
| (in-shift(l) E)
| (app/prim v ··· Ee···)
l, J, E[(up e)] →l +1,J,E[(in-up e)] INUP
l, J, E[(in-up v)] →l 1,J,E[v] OUTUP
l, J, E[(down e)] →l 1,J,E[(in-down e)] INDWN
l, J, E[(in-down v)] →l +1,J,E[v] OUTDWN
l, J, E[(λ
(x ···) e) CAPTURE
→l, J, E [(λ
l
(x ···) e)]
l, J, E[(app/prim (λ(x ···) e) v ···)] APPPRIM
→l, J, E [e{v ···/x ···}]
l
1
,J,E[(app/prim (λ
l
2
(x ···) e) v ···)] APPSHIFT
→l
2
,J,E[(in-shift(l
1
) e{v ···/x ···})]
l
2
,J,E[(in-shift(l
1
) v) →l
1
,J,E[v] SHIFT
Figure 2: Core syntax and reduction rules of the language.
our language using reduction steps. The relation is defined as
follows
2
: : L × J × E L × J × E
An evaluation context consists of an execution level l L ,a
join point stack J J and an expression e E . The reduc-
tion relation takes a level, a join point stack, and an expression and
maps this to a new evaluation step. Join point definition, aspect
deployment and the weaving mechanism is described in [10]. The
exception handling extension does not alter these definitions nor
any reduction rules of the original language.
Primitive application. The language features a primitive function
application, app/prim, that does not generate join points. It per-
forms a simple β
v
reduction of the expression. This mechanism is
required for tasks such as the initial application of the composed ad-
vice chain (and its recursive calls), and to perform the original com-
putation when all aspects (if any) have proceeded. This is shown in
rule APPPRIM.
Level-shifting operators. The up (down) level-shifting operator
embeds its inner expression in an in-up (in-down) expression,
which increases (lowers) the current execution level. When the
embedded expression is reduced to a value, the execution level is
decreased (increased) to the original level. This is specified by the
2
The complete semantics we provide includes the aspect environ-
ment in the reduction rules, omitted here for simplicity.
rules INUP,INDWN,OUTUP,OUTDWN. Aspect weaving ensures
that pointcuts and advices are evaluated with up, and that the last
proceed in the chain is evaluated with down [10].
Level-capturing functions. Level-capturing functions are defined
using λ
. A function value bound to level l is denoted λ
l
. Rule
CAPTURE shows that when a level-capturing function is defined, it
is tagged with the current execution level. Rule APPSHIFT shows
that when a level-capturing function is applied, it embeds the reduc-
tion of the application in an in-shift expression. By rule SHIFT,
when the expression reduces to a value, the execution level shifts
back to the level embedded in the in-shift form.
Aspect deployment. Aspects can be dynamically deployed. The de-
ploy expression takes a pointcut and an advice and adds the aspect
to the current aspect environment. To deploy aspects of aspects we
use the level-shifting operators to shift the level at which the deploy
expression is evaluated. The complete rules for aspect deployment
are shown in Tanter’s proposal [10], and are not changed in our
proposal.
3.2 Exception Handling Semantics
We introduce a standard exception handling mechanism [9], us-
ing the extensions shown in Figure 3. We extend the user-visible
syntax with the raise and try-with expressions and their respective
evaluation contexts. We also define an Exception normal form an-
notated with the level at the which the exception was raised. Then
we add reduction rules to specify the semantics of the raise and
try-with expression. In essence, our proposal consists in tagging
exceptions and handlers with their respective execution level; then,
an exception is only caught by a suitable handler if they are both
bound at the same level.
Safe default. A try e with e
h
expression contains a protected ex-
pression e and a handler expression e
h
. If an exception is raised
during the reduction of e, e
h
is evaluated, and the resulting func-
tion is applied to the exception, only if the level of the exception
matches the level of the handler. This default semantics ensures
that there is no interaction between aspect and base exceptions and
handler. For instance, if there are no explicit level shifts, the com-
putation of e happens at level 0. If an exception is thrown by the
base code, it will be a level-0 exception, which will therefore be
caught by the handler. Conversely, if the exception is thrown in an
aspect (at level 1), the handler will not catch the exception.
Certainly, there are situations where interaction is desired. To
this end, we exploit the fact that the handler is an expression to
be evaluated to install a handler in an upper (or lower) level us-
ing level-capturing functions and level shifting operators. This is
illustrated in Section 4.
Raising exceptions. The raise expression signals an exception that
embeds a value to carry information to the handler. Rule RAISE-
CAPTURE creates a tagged exception, which holds the execution
level at which the exception is raised. An exception bound at level
l is denoted (raise
l
v).
Exception propagation. The rule RERAISE deals with exception
propagation in nested raise expressions. An exception propagates
through the in-up and in-down expressions maintaining its tagged
level. For simplicity we omit the propagation rules here. They are
present in the downloadable complete semantics specification.
Handling exceptions. As reflected by rule TRYV, if the protected
expression of a try-with reduces to a value, the whole try-with
expression reduces to that value. Otherwise, the reduction is de-
termined by one of these rules: HNDEX1, H NDPROP 1, H NDEX2
and HNDPRO P 2. It is important to observe that the try ex with E
execution context ensures that the handler expression is only eval-

Expr e ::= ··· | (raise e) | (try e with e)
Exception ex ::= (raise
l
v)
EvalC tx E ::= ··· | (raise E) | (try E with e)
| (try ex with E)
l, J, E[(raise v)] RAISECAPTURE
→l, J, E [(raise
l
v)]
l, J, E[(raise (raise
l
1
e))] RERAISE
→l, J, E [(raise
l
1
e)]
l, J, E[(try v with e)] TRYV
→l
1
,J,E[v]
l, J, E[(try (raise
l
v) with (λ(x ···) e)] HNDEX1
→l, J, E [((λ(x ···) e) v)]
l, J, E[(try (raise
l
1
v) with (λ(x ···) e))] HNDPROP 1
→l, J, E [(raise
l
1
v)] where l
1
= l
l, J, E[(try (raise
l
1
v) with (λ
l
1
(x ···) e)] HNDEX2
→l
1
,J,E[(in-shift(l)((λ
l
1
(x ···) e) v))]
l, J, E[(try (raise
l
1
v) with (λ
l
2
(x ···) e))] HNDPROP 2
→l, J, E [(raise
l
1
v)] where l
1
= l
2
Figure 3: Exception handling extensions.
uated when an exception is raised in the evaluation of the protected
expression.
The HNDEX1 and HNDPRO P1 rules deal with normal function
handlers: if the exception level matches the current execution level,
the handler is applied; else, the exception propagates in search of a
suitable handler. Rules HNDEX2 and HNDPROP 2 deal with level-
capturing function handlers: regardless of the current execution
level, if the exception and handler level match then the handler is
applied shifting the current execution level to the level of the han-
dler; otherwise the exception keeps its propagation.
4. APPLICATIONS
To illustrate the benefits of our proposal, in this section we show
a set of four representative examples of interaction between aspect
and base exceptions and handlers: no interference between base ex-
ceptions and aspect handlers (Listing 2); no interference between
base handlers and aspect exceptions (Listing 3); an aspect han-
dler catching a base level exception (Listing 4), and a base handler
catching an aspect exception (Listing 5). These minimal examples
show that the semantics proposed in Section 3.2 solve the exception
conflation problem, while still enabling interesting programming
patterns, like aspects explicitly handling base exceptions.
For all the examples we assume that the pointcut associated to
the advice matches any function call. The advice is a function
which receives at least two parameters: p is the call to proceed, and
c is the return value of the pointcut application to the join point. We
also assume that the aspect is bound at level 1, so it observes only
joint points emitted from base function calls.
Additional parameters are required for each parameter of the ad-
vised function. In all the examples each function takes exactly one
argument, so each advice has three parameters: p, c, and arg which
holds the value of the advised function parameter.
In Listing 2 the function of the normal expression in the try-with
generates a call join point at level 1; the pointcut matches the join
point and the advice raises an exception at level 1. The exception
propagates back to the try-with expression and as the handler is
at level 0, the exception is not caught. In consequence, the base
expression reduces to (raise
1
#f).
1 ;; Advice
2 (λ (p c arg) (raise #f))
3
4 ;; Base code
5 (try ((λ (x) x) #t) with (λ (ex) ex))
Listing 2: By default there is no interference between base
exceptions and aspect handlers. Base expression evaluates to
(raise
1
#f).
In Listing 3 the base generates a call join point at level 0; when
the advice calls the proceed function p, an exception is raised at
level 0 (remember that the last call to proceed executes at the orig-
inal level, see Section 2) and as the handler in the advice is at level
1 the exception is uncaught. Thus, the base expression reduces to
(raise
0
#f).
1 ;; Advice
2 (λ (p c arg) (try (p arg) with (λ (ex) ex)))
3
4 ;; Base code
5 ((λ (x) (raise #f)) #f)
Listing 3: By default there is no interference between aspect
exceptions and base handlers. Base expression evaluates to
(raise
0
#f).
Listing 4 shows the same situation as in Listing 3, except for the
handler in the advice code. In this case, we shift down the eval-
uation of a level-capturing function using the down level-shifting
operator. This causes the handler function to be bound at level 0.
When the call to proceed raises the exception bound at level 0, the
handler catches it because they are both bound to the same level.
Note that the handler execution is a function application that hap-
pens at the level the handler is bound. This application also gen-
erates a call join point at level 0, and the advice applies again, but
in this case no exception is raised in the call to proceed. Hence the
original base code expression reduces to #f.
1 ;; Advice
2 (λ (p c arg) (try (p arg) with (down (λ
(ex) ex))))
3
4 ;; Base code
5 ((λ (x) (raise #f)) #f)
Listing 4: Using a level-capturing function and the down level-
shifting operator to catch a base exception in an aspect handler.
Base expression evaluates to #f.
Finally, Listing 5 shows the same situation as in Listing 2, but
with a different handler. In this case we use the up level-shifting
operator to bind the handler function at level 1. When the aspect ex-
ception propagates to the try-with expression, the handler catches
the exception and executes at level 1. In this case the advice does

not execute again because the call join generates at level 2, and the
aspect does not see it.
1 ;; Advice
2 (λ (p c arg) (raise #f))
3
4 ;; Base code
5 (try ((λ (x) x) #t) with (up (λ
(ex) ex))
Listing 5: Using a level-capturing function and the up level-
shifting operator to catch an aspect exception in a base handler.
Base expression evaluates to #t.
For each example, the handler has a normal function or a level-
capturing function. The dual situation in which the handler is of the
other kind is omitted. In the examples of Listing 2 and Listing 3
the program evaluates to the same result using a level-capturing
function. In the other two examples, using a non level-capturing
function the handler level does not match the exception level so the
exception propagates.
The examples show the key interactions between aspect and base
handlers and exceptions, and the mechanism that our semantics
provide to the programmer to specify the desired interaction. Other
situations like aspects of aspects can be reduced to one of the ex-
amples.
5. RELATED WORK
The first approach dealing with exception handling as a cross-
cutting concern was the study done by Lippert and Lopes [8]. They
refactored a Java business application framework, called JWAM,
using an old version of AspectJ to separate normal code from er-
ror handling code, in order to promote independent evolution and
reusability of each section. They significantly reduced the LOC
in the framework, managed to reuse common exception handling
code and described several limitations of the AspectJ version used.
Castor Filho et al. [7] studied the adequacy of AspectJ for mo-
dularizing and reusing exception-handling code. They studied five
systems: four object-oriented and one aspect-oriented. The object-
oriented systems had their exception-handling code refactored to
exception aspects. They obtained quantitative results applying a
metrics suite based on four quality attributes: separation of con-
cerns, coupling, cohesion and conciseness, to the systems. They
also obtained qualitative results, they discuss several issues like
best practices for aspect-oriented exception handling, interaction
between exception-handling aspects and other aspects and scala-
bility issues. Their main conclusions are that the mere use of as-
pects to handle exceptions is not sufficient to improve the quality
of software, a careful design from the early phases of development
is required to properly aspectize exception handling. A follow-up
study addresses different design scenarios to aspectize exception
handling in object-oriented systems [6].
Coelho et al. [3] study the interaction between aspects and ex-
ceptions in three systems with a Java and AspectJ versions avail-
able. They categorized the exception paths in the systems and the
most common handlers strategies. Using their own static analysis
tool they compare the object-oriented and aspect-oriented versions
of each system. Using this information they developed a catalogue
of exception-handling bug patterns in aspect-oriented programs [4].
6. CONCLUSION AND FUTURE WORK
In this paper we showed that interaction between aspect and base
exceptions and handlers is prone to unintended execution of han-
dlers and a lack of flexibility for the programmer. This situation
ocurrs because the exception handling mechanisms do not distin-
guish between aspect and base exceptions. As a solution, we de-
signed and described the semantics of a higher-order aspect lan-
guage with execution levels and exceptions. Our language by de-
fault ensures there is no interaction between aspect and base han-
dlers and exceptions and provides level-shifting operators to spec-
ify the interaction between them. We then showed four represen-
tative examples of interaction between aspects and base exceptions
and how our language solves the exception conflation problem by
default, and still provides the necessary flexibility when needed.
To further illustrate the benefits of our proposal, we plan to ex-
tend the AspectJ implementation with execution levels described
by Tanter et al. in [11] with our exception handling semantics. Us-
ing this implementation we will make case studies similar to the
ones done by Coelho et al. in [3], as well as some others like using
the Contract4J design-by-contract framework. Other issues to con-
sider are the interactions between exception handling mechanisms
and the type system, the contrasts between languages with checked
and unchecked exceptions, such as Java and C#; and the presence
of finally blocks.
7. REFERENCES
[1] Proceedings of the 9th ACM International Conference on
Aspect-Oriented Software Development (AOSD 2010), Rennes and
Saint Malo, France, Mar. 2010. ACM Press.
[2] S. Chiba, G. Kiczales, and J. Lamping. Avoiding confusion in
metacircularity: The meta-helix. In Proceedings of the 2nd
International Symposium on Object Technologies for Advanced
Software (ISOTAS’96), volume 1049 of Lecture Notes in Computer
Science, pages 157–172. Springer-Verlag, 1996.
[3] R. Coelho, A. Rashid, A. Garcia, N. Cacho, U. Kulesza, A. Staa, and
C. Lucena. Assessing the impact of aspects on exception flows: An
exploratory study. In J. Vitek, editor, Proceedings of the 22nd
European Conference on Object-oriented Programming (ECOOP
2008), number 5142 in Lecture Notes in Computer Science, pages
207–234, Paphos, Cyprus, july 2008. Springer-Verlag.
[4] R. Coelho, A. Rashid, A. von Staa, J. Noble, U. Kulesza, and
C. Lucena. A catalogue of bug patterns for exception handling in
aspect-oriented programs. In PLoP ’08: Proceedings of the 15th
Conference on Pattern Languages of Programs, pages 1–13, New
York, NY, USA, 2008. ACM.
[5] M. Felleisen, R. B. Findler, and M. Flatt. Semantics Engineering
with PLT Redex. MIT Press, 2009.
[6] F. Filho, A. Garcia, and C. Rubira. Extracting error handling to
aspects: A cookbook. In Software Maintenance, 2007. ICSM 2007.
IEEE International Conference on, pages 134 –143, Oct. 2007.
[7] F. C. Filho, N. Cacho, E. Figueiredo, R. Maranhão, A. Garcia, and
C. M. F. Rubira. Exceptions and aspects: the devil is in the details. In
Proceedings of the 14th ACM SIGSOFT international symposium on
Foundations of software engineering, SIGSOFT ’06/FSE-14, pages
152–162, New York, NY, USA, 2006. ACM.
[8] M. Lippert and C. V. Lopes. A study on exception detection and
handling using aspect-oriented programming. In ICSE ’00:
Proceedings of the 22nd international conference on Software
engineering, New York, NY, USA, 2000. ACM.
[9] B. C. Pierce. Types and programming languages. MIT Press,
Cambridge, MA, USA, 2002.
[10] É. Tanter. Execution levels for aspect-oriented programming. In
AOSD 2010 [1], pages 37–48. Best Paper Award.
[11] É. Tanter, P. Moret, W. Binder, and D. Ansaloni. Composition of
dynamic analysis aspects. In Proceedings of the 9th ACM SIGPLAN
International Conference on Generative Programming and
Component Engineering (GPCE 2010), pages 113–122, Eindhoven,
The Netherlands, Oct. 2010. ACM Press.
[12] R. Toledo, P. Leger, and É. Tanter. AspectScript: Expressive aspects
for the Web. In AOSD 2010 [1], pages 13–24.
Citations
More filters

Proceedings ArticleDOI
24 Mar 2013
TL;DR: The utility of Ptolemy-X's exception flow reasoning is evaluated by applying it to understand a set of aspect-oriented (AO) bug patterns and its semantics including its sound static semantics are presented.
Abstract: Modular understanding of behaviors and flows of exceptions may help in their better use and handling. Such reasoning tasks about exceptions face unique challenges in event-based implicit invocation (II) languages that allow subjects to implicitly invoke observers, and run the observers in a chain. In this work, we illustrate these challenge in Ptolemy and propose Ptolemy-X that enables modular reasoning about behaviors and flows of exceptions for event announcement and handling. Ptolemy-X's exception-aware specification expressions and boundary exceptions limit the set of (un)checked exceptions of subjects and observers of an event. Exceptional postconditions specify the behaviors of these exceptions. Greybox specifications specify the flows of these exceptions among the observers in the chain. Ptolemy-X's type system and refinement rules enforce these specifications and thus enable its modular reasoning. We evaluate the utility of Ptolemy-X's exception flow reasoning by applying it to understand a set of aspect-oriented (AO) bug patterns. We also present Ptolemy-X's semantics including its sound static semantics.

21 citations


Journal ArticleDOI
TL;DR: This paper introduces execution levels in order to address the issue of infinite regression of aspect-oriented programs, and adopts a defensive default that avoids infinite regression, and gives advanced programmers the means to override this default using level-shifting operators.
Abstract: In aspect-oriented programming (AOP) languages, advice evaluation is usually considered as part of the base program evaluation. This is also the case for certain pointcuts, such as if pointcuts in AspectJ, or simply all pointcuts in higher-order aspect languages like AspectScheme. While viewing aspects as part of base level computation clearly distinguishes AOP from reflection, it also comes at a price: because aspects observe base level computation, evaluating pointcuts and advice at the base level can trigger infinite regression. To avoid these pitfalls, aspect languages propose ad-hoc mechanisms, which increase the complexity for programmers while being insufficient in many cases. After shedding light on the many facets of the issue, this paper proposes to clarify the situation by introducing levels of execution in the programming language, thereby allowing aspects to observe and run at specific, possibly different, levels. We adopt a defensive default that avoids infinite regression, and gives advanced programmers the means to override this default using level-shifting operators. We then study execution levels both in practice and in theory. First, we study the relevance of the issues addressed by execution levels in existing aspect-oriented programs. We then formalize the semantics of execution levels and prove that the default semantics is indeed free of a certain form of infinite regression, which we call aspect loops. Finally, we report on existing implementations of execution levels for aspect-oriented extensions of Scheme, JavaScript and Java, discussing their implementation techniques and current applications. We introduce execution levels in order to address the issue of infinite regression of aspect-oriented programs.This issue is prevalent in existing AspectJ projects and a textbook code.A formalization of execution levels shows that certain kinds of loops are indeed avoided.Execution levels can be implemented using different techniques, possibly very efficiently.

20 citations


Cites background from "A semantics for execution levels wi..."

  • ...Additional content on exception handling appears in the Proceedings of the Foundations of Aspect Languages Workshop 2011 [24]....

    [...]


Proceedings ArticleDOI
24 Mar 2013
TL;DR: The use of monads brings type-based reasoning about effects for the first time in the pointcut/advice setting, thereby practically combining Open Modules and EffectiveAdvice, and enables modular extensions of the aspect language.
Abstract: We describe a novel approach to embed pointcut/advice aspects in a typed functional programming language like Haskell. Aspects are first-class, can be deployed dynamically, and the pointcut language is extensible. Type soundness is guaranteed by exploiting the underlying type system, in particular phantom types and a new anti-unification type class. The use of monads brings type-based reasoning about effects for the first time in the pointcut/advice setting, thereby practically combining Open Modules and EffectiveAdvice, and enables modular extensions of the aspect language.

15 citations


Cites background from "A semantics for execution levels wi..."

  • ...He illustrated the extensibility approach with execution levels [32] and level-aware exception handling [10]....

    [...]


Proceedings ArticleDOI
26 Mar 2012
TL;DR: Monascheme is presented, an extensible aspect-oriented programming language based on monadic aspect weaving, enabling easy, simple and modular prototyping and a first step towards a framework for controlling aspects with monads in the pointcut and advice model of AOP.
Abstract: We present Monascheme, an extensible aspect-oriented programming language based on monadic aspect weaving. Extensions to the aspect language are defined as monads, enabling easy, simple and modular prototyping. The language is implemented as an embedded language in Racket. We illustrate the approach with an execution level monad and a level-aware exception transformer. Semantic variations can be obtained through monad combinations. This work is also a first step towards a framework for controlling aspects with monads in the pointcut and advice model of AOP.

10 citations


Cites background from "A semantics for execution levels wi..."

  • ...A Practical Monadic Aspect Weaver Ismael Figueroa * Éric Tanter PLEIAD Laboratory Computer Science Department (DCC) University of Chile Chile {i.guero,etanter}@dcc.uchile.cl Abstract We present Monascheme, an extensible aspect-oriented pro­gramming language based on monadic aspect weaving....

    [...]

  • ...He then defined the execution level monad, and two exception transformers to provide flat (standard exceptions that do not have access to the level of execution), and levelaware [4] exceptions to execution levels....

    [...]

  • ...[4] I. Figueroa and É. Tanter....

    [...]

  • ...In subsequent work, Figueroa and Tanter [4] address the exception conflation problem, that is, the problematic interactions between aspect and base code in presence of an exception handling mechanism....

    [...]

  • ...Tanter proposed execution levels for AOP [9] as a means to structure computation and avoid in.nite regres­sion by default, while providing .exibility to the program­mer when required....

    [...]


Book ChapterDOI
01 Jan 2014
TL;DR: This work brings type-based reasoning about effects for the first time in the pointcut/advice model, in a framework that is both expressive and extensible; thus allowing development of robust aspect-oriented systems as well as being a useful research tool for experimenting with new aspect semantics.
Abstract: Aspect-oriented programming (AOP) aims to enhance modularity and reusability in software systems by offering an abstraction mechanism to deal with crosscutting concerns. However, in most general-purpose aspect languages aspects have almost unrestricted power, eventually conflicting with these goals. In this work we present Effective Aspects: a novel approach to embed the pointcut/advice model of AOP in a statically typed functional programming language like Haskell. Our work extends EffectiveAdvice, by Oliveira, Schrijvers, and Cook; which lacks quantification, and explores how to exploit the monadic setting in the full pointcut/advice model. Type soundness is guaranteed by exploiting the underlying type system, in particular phantom types and a new anti-unification type class. Aspects are first-class, can be deployed dynamically, and the pointcut language is extensible, therefore combining the flexibility of dynamically typed aspect languages with the guarantees of a static type system. Monads enables us to directly reason about computational effects both in aspects and base programs using traditional monadic techniques. Using this we extend Aldrich’s notion of Open Modules with effects, and also with protected pointcut interfaces to external advising. These restrictions are enforced statically using the type system. Also, we adapt the techniques of EffectiveAdvice to reason about and enforce control flow properties. Moreover, we show how to control effect interference using the parametricity-based approach of EffectiveAdvice. However, this approach falls short when dealing with interference between multiple aspects. We propose a different approach using monad views, a recently developed technique for handling the monad stack. Finally, we exploit the properties of our monadic weaver to enable the modular construction of new semantics for aspect scoping and weaving. These semantics also benefit fully from the monadic reasoning mechanisms present in the language. This work brings type-based reasoning about effects for the first time in the pointcut/advice model, in a framework that is both expressive and extensible; thus allowing development of robust aspect-oriented systems as well as being a useful research tool for experimenting with new aspect semantics.

9 citations


Cites background from "A semantics for execution levels wi..."

  • ...He illustrated the extensibility approach with execution levels [41] and levelaware exception handling [13]....

    [...]


References
More filters

Book
01 Jan 2002
TL;DR: This text provides a comprehensive introduction both to type systems in computer science and to the basic theory of programming languages, with a variety of approaches to modeling the features of object-oriented languages.
Abstract: A type system is a syntactic method for automatically checking the absence of certain erroneous behaviors by classifying program phrases according to the kinds of values they compute. The study of type systems -- and of programming languages from a type-theoretic perspective -- has important applications in software engineering, language design, high-performance compilers, and security.This text provides a comprehensive introduction both to type systems in computer science and to the basic theory of programming languages. The approach is pragmatic and operational; each new concept is motivated by programming examples and the more theoretical sections are driven by the needs of implementations. Each chapter is accompanied by numerous exercises and solutions, as well as a running implementation, available via the Web. Dependencies between chapters are explicitly identified, allowing readers to choose a variety of paths through the material.The core topics include the untyped lambda-calculus, simple type systems, type reconstruction, universal and existential polymorphism, subtyping, bounded quantification, recursive types, kinds, and type operators. Extended case studies develop a variety of approaches to modeling the features of object-oriented languages.

2,297 citations


"A semantics for execution levels wi..." refers methods in this paper

  • ...We introduce a standard exception handling mechanism [9], using the extensions shown in Figure 3....

    [...]


Book
01 Jan 2009
TL;DR: This text is the first comprehensive presentation of reduction semantics in one volume and introduces the first reliable and easy-to-use tool set for such forms of semantics, and presents a framework for the formulation of language models as PLT Redex models.
Abstract: This text is the first comprehensive presentation of reduction semantics in one volume; it also introduces the first reliable and easy-to-use tool set for such forms of semantics. Software engineers have long known that automatic tool support is critical for rapid prototyping and modeling, and this book is addressed to the working semantics engineer (graduate student or professional language designer). The book comes with a prototyping tool suite to develop, explore, test, debug, and publish semantic models of programming languages. With PLT Redex, semanticists can formulate models as grammars and reduction models on their computers with the ease of paper and pencil. The text first presents a framework for the formulation of language models, focusing on equational calculi and abstract machines, then introduces PLT Redex, a suite of software tools for expressing these models as PLT Redex models. Finally, experts describe a range of models formulated in Redex. PLT Redex comes with the PLT Scheme implementation, available free at http://www.plt-scheme.org/. Readers can download the software and experiment with Redex as they work their way through the book. For more information (including the preface, a sample syllabus, and a quick introduction to Redex), see the Redex website at http://redex.plt-scheme.org/. Matthias Felleisen, Robert Bruce Findler, and Matthew Flatt are the authors (with Shiram Krishnamurthi) of How to Design Programs: An Introduction to Programming and Computing, also published by the MIT Press.

269 citations


"A semantics for execution levels wi..." refers methods in this paper

  • ...The complete semantics for the original language and the exception handling extensions are defined using PLT Redex, a domain-specific language for specifying reduction semantics [5]....

    [...]


Proceedings ArticleDOI
01 Jun 2000
TL;DR: This study took an existing framework written in Java/sup TM/, the JWAM framework, and partially reengineered its exception detection and handling aspects using AspectJ, an aspect oriented programming extension to Java, and found it supported implementations that drastically reduced the portion of the code related to exception Detection and handling.
Abstract: Aspect oriented programming (AOP) is intended to ease situations that involve many kinds of code tangling. The paper reports on a study to investigate AOP's ability to ease tangling related to exception detection and handling. We took an existing framework written in Java/sup TM/, the JWAM framework, and partially reengineered its exception detection and handling aspects using AspectJ/sup TM/, an aspect oriented programming extension to Java. We found that AspectJ supported implementations that drastically reduced the portion of the code related to exception detection and handling. In one scenario, we were able to reduce that code by a factor of 4. We also found that, with respect to the original implementation in plain Java, AspectJ provided better support for different configurations of exceptional behaviors, more tolerance for changes in the specifications of exceptional behaviors, better support for incremental development, better reuse, automatic enforcement of contracts in applications that use the framework, and cleaner program texts. We also found some weaknesses of AspectJ that should be addressed in the future.

257 citations


Additional excerpts

  • ...[8] M. Lippert and C. V. Lopes....

    [...]

  • ...RELATED WORK The .rst approach dealing with exception handling as a cross­cutting concern was the study done by Lippert and Lopes [8]....

    [...]

  • ...The first approach dealing with exception handling as a crosscutting concern was the study done by Lippert and Lopes [8]....

    [...]



Proceedings ArticleDOI
05 Nov 2006
TL;DR: An in-depth study of the adequacy of the AspectJ language for modularizing exception handling code and performs quantitative assessments of four systems based on four quality attributes, namely separation of concerns, coupling, cohesion, and conciseness.
Abstract: It is usually assumed that the implementation of exception handling can be better modularized by the use of aspect-oriented programming (AOP). However, the trade-offs involved in using AOP with this goal are not well-understood. This paper presents an in-depth study of the adequacy of the AspectJ language for modularizing exception handling code. The study consisted in refactoring existing applications so that the code responsible for implementing heterogeneous error handling strategies was moved to separate aspects. We have performed quantitative assessments of four systems - three object-oriented and one aspect-oriented - based on four quality attributes, namely separation of concerns, coupling, cohesion, and conciseness. Our investigation also included a multi-perspective analysis of the refactored systems, including (i) the reusability of the aspectized error handling code, (ii) the beneficial and harmful aspectization scenarios, and (iii) the scalability of AOP to aspectize exception handling in the presence of other crosscutting concerns.

132 citations


"A semantics for execution levels wi..." refers background in this paper

  • ...[7] studied the adequacy of AspectJ for modularizing and reusing exception-handling code....

    [...]


Frequently Asked Questions (2)
Q1. What have the authors contributed in "A semantics for execution levels with exceptions" ?

Specific instances of this issue have been identified by others researchers. Consequently, the authors propose a semantics for an aspect-oriented language with execution levels and an exception handling mechanism that solves the exception conflation problem. By default, the language ensures there is no interaction between base and aspect exceptions and handlers, and provides level-shifting operators to flexibly specify interaction between them when required. The authors illustrate the benefits of their proposal with a representative set of examples. 

To further illustrate the benefits of their proposal, the authors plan to extend the AspectJ implementation with execution levels described by Tanter et al. in [ 11 ] with their exception handling semantics. Using this implementation the authors will make case studies similar to the ones done by Coelho et al. in [ 3 ], as well as some others like using the Contract4J design-by-contract framework.