Ambient-Oriented Programming

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Ambient-Oriented Exception Handling =====
[[http://soft.vub.ac.be/~smostinc/|Stijn Mostinckx]]

{{ research:exceptions.jpg?200 }}

Exception handling mechanisms have become an essential tool for software development. Since exceptions are propagated automatically by the language support, methods need to be aware only of the particular exceptions they can handle locally. This degree of obliviousness is particularly useful in a context where exceptions are bound to arise not only to report logical errors but also as a response to environmental failures (e.g. long-lasting disconnection).

== Motivation ==

The motivation for an ambient-oriented exception handling mechanism stems from the fact that traditional try-catch-based exception handling mechanisms cannot be reconciled with a programming model based on non-blocking communication as prescribed by the [[:start|AmOP paradigm]]. This combination yields a set of concrete problems which are addressed by the ambient-oriented exception handling mechanism.

  - **Loss of Handling Context**: Traditionally, ''try-catch'' associates exception handlers with a particular position on the runtime stack. However, since communication is non-blocking, the runtime stack may have been altered substantially by the time the exception is reported. As a consequence, the exception may not be handled properly if at all. This problem can be circumvented by attributing handler blocks to [[Wp>Future_(programming)|futures]] (actor placeholders for the result to be computed). AmbientTalk therefore has adopted the ''when-catch'' construct from the [[http://www.e-lang.org|E programming language]].
  - **Concurrent Exceptions**: On top of the ''when-catch'' construct, which allows handling exceptions on a per-message basis, additional support is needed to support protecting an entire block of code with a set of exception handlers (as with a ''try-catch'' block). When the block of code consists of various messages being sent asynchronously, each message may concurrently raise an exception. AmbientTalk allows dealing with these concurrent exceptions through the ''group'' construct which implicitly groups all returned futures and allows specifying how to handle an ensemble of concurrently raised exceptions.
  - **Implicit Dependencies**: In order to improve the resilience of an application to the temporal unavailability of a collaborating device, a commonly used technique is to minimize the required synchronization between devices. This technique often boils down to optimistically assuming that the partner devices will behave as expected. Obviously when this assumption is violated, all collaborating partners should be warned and should handled the exception collaboratively. AmbientTalk provides basic support for this by offering a ''conversation'' to which all partners listen for reported exceptions and to whom exceptions are signalled implicitly.

== Design == 
The design of the exception handling model is closely coupled with the design of the [[Wp>Future_(programming)|futures]] abstraction of which it is a natural extension. The ambient-oriented exception handling relies allowing futures to be ruined transitively by exceptions, in combination with the introduction of the ''when-catch'' construct described above. The ''group'' and ''conversation'' constructs capture recurrent - and conceptually idiosyncratic - patterns of use of this basic abstraction.

== Implementation ==
<note warning>The implementation of the ambient-oriented exception handling is being redesigned as part of the development of AmbientTalk/2. </note>

== Further Reading ==
//Ambient-Oriented Exception Handling//, Stijn Mostinckx, Jessie Dedecker, Elisa Gonzalez Boix, Tom Van Cutsem, Wolfgang De Meuter. In "//Advanced Topics in Exception Handling Techniques//", C. Dony, J. L. Knudsen, A. Romanovsky, A. Tripathi (eds.), Lect. Not. Comp. Sc. 4119, pp. 141-160, Springer Verlag, 2006