(Internal classification: anecdotical)
Reference paper: “Stayin' alert:: moulding failure and exceptions to your needs” Anya Helene Bagge, Valentin David, Magne Haveraaen, Karl Trygve Kalleberg in Proceedings of the 5th international conference on Generative programming and component engineering, http://portal.acm.org/citation.cfm?id=1173706.1173747, 2006
A simplified version for the Tiny Imperative Language is also presented in “DSAL = library+notation: Program Transformation for Domain-Specific Aspect Languages” Anya Helene Bagge Karl Trygve Kalleberg, In DSAL06 workshop, http://dsal.dcc.uchile.cl/2006/accepted_papers.html, 2006.
The DSAL06 workshop paper argues for DSAL construction where “the DSAL [is] a meta-program that is executed at compile-time, and that will rewrite the subject program according to the implemented DSAL semantics.” The semantics is implemented as a library for a program transformation tool, and the DSAL is syntactic sugar. The appeal of this is that it boils down DSAL development to DSL development, which allows us to use the experience and tools that have been developed for that.
Alert alows for the separate specification of exception handling, both on the throwing side as on the catching side of the exception.
“[…] failure handling is largely rigid. The alert reporting and handling are tangled, and the implementer must always choose a mechanism when implementing a function, but in doing so also makes an implicit choice about the handling policy.”
The DSAL proposed is a language extension that has been implemented for C (as well as proposed for C++ and Java). It allows for “user-defined alert handling and handling mechanisms for exceptional behavior. The extension [provides for] user-defined alert handling and reporting at a wide range of granularities […] and to declare separately the desired handling policies.”
While it does address a cross-cutting concern in a separate way, it can be argued that this is not an aspect language but just a language extension. This as the separation is not as strict as with other languages. The aspect code still is declared within the source code of the base, and still can be tangled with the base. Nonetheless, the authors state that: “One could consider our language extension as a domain-specific aspect language for error handling.” Note that while we are including it in this wiki we do not wish to take sides in this debate.
Alert consists of 3 parts: declaring new alerts, specifying alert reporting and alert handlers. The grammars for these 3 parts are detailed in the paper.
Alerts are declared using syntax of enum, extended with the possibility to specify multiple super-alerts.
alert {Retry, AskUser, FatalSys, FatalBug, UserMistake};
alert {eNoEnt : AskUser };
alert {eBadF, eIO} : FatalBug : UserMistake;
The first line declares a number of alerts, the second declares one alert as a sub-alert, the third declares two alerts with multiple common super-alerts.
“Alert reports are specified at the callee [emphasis added] side with an alert clause in the function declaration”. This clause can check for pre and postconditions (and exceptions in C++ or Java) using a conditional expression. For example, the code below has a postcondition on the return value and the global variable ERRNO.
int insert(tbl t, key k, val v) alert eNoMem post (value == -1 && errno = ENOMEM);
The pseudo-variable value in the conditional expression refers to the return value of the function call. “The condition expressions may be arbitrarily complex but should only use globally accessible names, arguments to the call and [the pseudo-variable] value.” Preconditions are checked using the keyword pre instead of post.
Functions can be grouped into funspaces: sets of functions. Set membership can be defined by enumerating functions as well as using wildcards. The set union operator is also provided. Alert reporting can be specified on a funspace as well.
“There are two alert handling constructs: on, for specifying an alert handler at any scoping level, down to a single statement, and the handler operator <::, which specifies a handler for a single expression”. Within the statements of the alert handler, the keywords use and retry may be used. use specifies that the program should continue, using the value of the supplied expression as return value of the function.
on NotFound in lookup() use "Doe, Jane";
retry tries the call again, with an optional maximum retry count, and an optional list of parameters as arguments.
on NotFoundError in readFile(char * name) {
warn("trying again ...");
char *name = askUser();
if (name != null) retry(name) max 5;
warn("giving up...");
use ""; }
The handler operator <:: allows alerts to be handled at the expression level, for example:
printf("result: %s", lookup(t,k) <:NotFound: "Unknown");
In this code, the argument between : indicates which alerts must be handled, if empty all alerts are handled.
Lastly, alert also allows for named exception handlers which can be called from the handling constructs, as well as for alerts to be parametrized. We do not discuss these here and instead refer to the paper.
The reference paper does not provide a typical usage example beyond the examples used to explain the language.
The paper does not mention any restrictions on the statements in an alert handler or the conditions in an alert reporter.
Weaving is done through source code transformation (using StrategoXT), “translating the extended C code to standard C. […] Minimal type analysis is then performed to check that the handlers are type consistent with the functions they will be applied to.”