Ambient-Oriented Programming

User Tools

Site Tools

Trace:
research:exceptions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
research:exceptions [2009/11/30 17:17] – dharnieresearch:exceptions [2009/11/30 17:18] (current) – dharnie
Line 10: Line 10:
 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. 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]].+  - **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.   - **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.   - **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 ==  == 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.+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 == == Implementation ==
research/exceptions.txt · Last modified: by dharnie