Exception Handling Mechanism in FLE

1. Exception Handling Mechanism in FLE www.openflx.org Thesis Defense of Yimeng Li

2. 1 2 3 4 EHM Overview Existing EHMs EHM in FLE Summary Outline

3. EHM Overview • Exception are unusual events that occur during program execution • Exception usually contains some diagnostic information. • What is the exception. • Why it is raised. • etc. • EHM is designed for specifying the behavior of programs when exceptions occur.

4. Problem with Existing Art • Exception handling programs are difficult to develop • Typically not reusable. • Contain more bugs than normal processing programs. • Difficult to debug.

5. EHM overview • Major components of EHM • Exception definition • What is the exception • Exception handler specification • How to deal with the exception • Exception reporting and propagation mechanism • Raise the exception and search for the proper handler • Exception return models • Where to return after the exception is handled • We’ll explain the functionality and existing art of each component. • OOP EHM is used as the major example to illustrate existing art. Other techniques will be describes if necessary.

6. 1 2 3 4 Overview of EHM Existing EHMs EHM in FLE Demo Outline

7. Existing Art Exception Handling Mechanism Exception Definition Exception Handler Reporting & Propagation Return Model

8. Handler Handler IOException RemoteException SocketException Exception Definition • In OOP, exceptions are defined as objects. • Class hierarchy makes exception handling more flexible. • Handler can be designed for a specific type of exception or a group of exceptions.

9. Checked Exception • JAVA provides support to checked exceptions that are required to be handled before compilation. • It increases the robustness • manifestation of unanticipated checked exceptions at run-time is prevented. • It decreases the adaptability • The handler must be written for the checked exceptions even if they cannot be signaled. • In practice we can often find these dummy handlers throughout the program • Some propose soften checked exception • Wrap checked exception into unchecked the exceptions. • Trade robustness for more adaptability

10. Existing EHMs Exception Handling Mechanism Exception Definition Exception Handler Reporting & Propagation Return Model

11. Exception Handler Specification • The programs that deals with the exceptions are called exception handlers. • It analyzes the exception and performscertain operations • Correcting errors. • Logging the errors. • Re-throwing exceptions. • etc.

12. int main(int argc,char **argv) • { • int s; • s = socket(PF_LOCAL,SOCK_DGRAM,0); • if ( s == -1 ) • { // exception • // handling code here • } • printf("s = %d;\n",s); • return 0; • } Exception Handler Specification • Exception handlers entangles with normal processing code. • Poor reusability • Poor portability • Poor performance • Not only Programmer has to write code to test the return value, the computer will have to test it. The testing routines often occupy a lot of the run-time resources.

13. try{ int s; s = Socket(PF_LOCAL,SOCK_DGRAM,0); printf("s = %d;\n",s); return 0; }catch(SocketException e){ // exception handling code } Exception Handler Specification • OOP alleviates this issue by try-catch design pattern. • Normal processing code resides in try blocks while exception handling code lies in catch blocks. • Free programmer from testing the return values • It has not solve the problem • line-by-line entanglement is replaced with block-by-block entanglement try{ // normal processing code }catch(Exception e){ // exception handling code }

14. Existing EHMs Exception Handling Mechanism Exception Definition Exception Handler Reporting & Propagation Return Model

15. M1 M2 M5 M4 M3 Ex Reporting and Propagation • Responsible for raising the exception and searching for the proper handler. • Facilities provided by OOP • Exception can be thrown under different error conditions • Free programmer from testing the return values • Stack unwinding mechanism is used to search for proper handlers • Back tracking of the original execution flow

16. M1 M2 M5 M4 M3 Handler Handler Handler Handler Ex Exception Propagation • Problems • Stack unwinding increases the complexity of the program • How to handle the exception may depends on the call stack. • Lack of scoping • Scatterness of handler

17. Existing EHMs Exception Handling Mechanism Exception Definition Exception Handler Reporting & Propagation Return Model

18. Exception Return Models • Define the control flow after the exception handling. • Three basic return models • Termination • Retry • Resume

19. Termination Return Model • Control flow transfers from the exception raise point to the handler, terminating the intervene blocks

20. Restart point This part of the code will be executed again Retry Return Model • Control flow transfers to the preset restarting point.

21. Exception raise point Resume Return Model • Control flow transfers to the very next instruction after the exception raise point.

22. try{ getResource(FILE_1); }catch (ResourceException ex){ // handling code } try{ getResource(FILE_2); }catch (ResourceException ex){ // handling code } try{ getResource(FILE_3); }catch (ResourceException ex){ // handling code } try{ getResource(FILE_1); getResource(FILE_2); getResource(FILE_3); }resume (ResourceException ex){ // handling code } Resume Simulated with Termination Exception return Model • Although retry and resume models can be simulated using termination model, it results in awkward programs.

23. 1 2 3 4 Overview of EHM Existing EHMs EHM in FLE Summary Overview

24. Objective of FLE EHM • Achieve better separation of concern in exception handling • Exception handling code and normal processing code can be written as separate and reusable modules • Exception handling code is reusable • Changes in exception handling policies do not require modification in normal processing code.

25. Basics for FLE • FLE is non-procedural that it does not specify the exact order of execution of the code. • Programmer first defines a model for his application. • The model is composed of a domain statement • and a special feature called an anchor feature that implements the basic functionalities. • Other features are built around the anchor feature as an extension to the anchor feature. • Features are put together in feature packages • A feature package may be considered as a feature in another feature package.

26. Features and feature packages are reusable

27. Existing EHMs Exception Handling Mechanism Exception Definition Exception Handler Reporting & Propagation Return Model

28. domain BasicTelephonyWithExc { variables: // domain variables events: // domain events exceptions: RingCktBrokeException; ConfCktBrokeException; // and others resources: // resources declaration } Exception Definition • Exceptions are object as in OOP • Class hierarchy still applies • Domain Specific Exceptions • Associated with Domain • Typically are essential recoverable exceptions • Regarded as checked exceptions • Policy for checked exceptions • Warnings are provided instead of compile time errors. • Robustness • Flexibility

29. Existing EHMs Exception Handling Mechanism Exception Definition Exception Handler Reporting & Propagation Return Model

30. exception_prog_name { context: { condition: condition; event:trigger; } exception:trigger_exception; { // exception handing code } } exception_prog_name { context: {feature.prog_name} exception: trigger_exception; { // exception handing code } } General context EPU Specific context EPU Exception Handler in FLE • The exception handlers in FLE EHM are exception program units (EPU). • Two kinds of syntax are provided • An EPU will catch the exception that thrown from the PU(s) that matches the context.

31. Exception Handler in FLE • EPUs can be grouped together to form an exception feature • Note: Exception feature may also contain normal program units if they are dealing with regular events that are regarded as unanticipated. • Interaction resolution • If multiple exception features in a feature package interact, the programmer can use precedence list to solve the conflict. • Example

32. exception feature DamageControl { domain: BasicTelephonyWithExc; anchor: Pots; IllegalOnhook { condition: state.equals (State.IDLE); event: Onhook; { System.out.println (“Illegal Onhook”); fone.disable (); } BrokenRingCKT { context: {all}; exception: RingCktBrokeException; { System.out.println (“Ring CKT broken”); } // Other program units not shown } Damage control Exception Feature

33. exception feature CatchAll { domain: BasicTelephonyWithExc; anchor: Pots; catch_AllExceptions { context: {all}; exception: any; { System.out.println (“CatchAll: Exception Caught”); This.dump (domain, event); } } catch_AllEvent { condition: all; event: any; { System.out.println (“CatchAll: Unexpected Condition and Event”); This.dump (domain, event); } } CatchAll Exception Feature

34. feature package RobustPhone { domain: BasicTelephonyWithExc; features: Pots, DamageControl, CatchAll; priorityPrecedence: DamageControl, Pots, CatchAll; } RobustPhone feature package • DamageControl and CatchAll interact with each other • The interaction can be solve with the precedence list given in the figure below • Catchall will only process the events that are not handled in DamangeControl and Pots. • Both exceptions features are reusable; they can be include in other feature packages to perform the same function. • It is difficult to implement these reusable feature in conventional languages.

35. Advantages • Programmer can develop exception handling code and normal processing code separately • Increases the reusability and portability • Exception Handler in FLE EHM are reusable • Reusability of normal processing code is increased • If the exception handling policy changes, the programmer can develop another set of exception features and include them with existing normal processing features in another feature package

36. Existing EHMs Exception Handling Mechanism Exception Definition Exception Handler Reporting & Propagation Return Model

37. Exception Reporting and Propagation • Exception Reporting • Exception can be thrown as in OOP • Exception propagation is decided by the context of the current program unit. • Programmer does not have to worry about the execution path. • Benefit from non-procedural design of FLE.

38. Ex1 Ex1 Propagation Example One of the exceptions that thrown in the program unit that of context1 Contain handler for Ex1 under context1. F2 F1 EF FP1

39. Ex1 EF2 Another Example • FP2 contains FP1 and EF2 that handles Ex1 under context1 • The precedence is set as EF2 ->FP1 FP1 F2 EF F1 FP2

40. Advantages • Simple exception propagation mechanism • Propagation of exceptions only depends on the context and the exception type. • Reduces the complexity of stack-unwinding. • Precedent list solves the interaction among exception features in a clear way.

41. Existing EHMs Exception Handling Mechanism Exception Definition Exception Handler Reporting & Propagation Return Model

42. exception_prog_name : retry{ context: { condition: condition; event:trigger; } exception:trigger_exception; { // exception handing code } } exception_prog_name : resume{ context: { condition: condition; event:trigger; } exception:trigger_exception; { // exception handing code } } Retry EPU Resume EPU Exception Handling Return Models • FLE EHM support all three basic return models • All exception program unit adapts the termination model if not specified explicitly. • retry and resume model can be applied when specified. • This helps the programmer to develop programs to meet various application requirements.

43. 1 2 3 4 Overview of EHM Existing EHMs EHM in FLE Summary Overview

44. Summary • Exception are defined as Object with special properties • Class hierarchy applies • Unhandled checked exceptions result in compilation warnings • Exception handling code and normal processing code can be developed separately • Allow programmer to focus on one task at a time • Increases reusability and portability • Clear exception propagation. • Context dependent • Reduces the complexity of programs • Precedence list enables a neat interaction resolution • Complete support to all three exception return models.

45. Contribution • Mr. Karthik Ramachandran proposed the following concepts: • Exception feature • Domain specific exceptions • New Contribution • New semantics of domain specific exceptions • Exception propagation • Exception return models • Implementation

46. Future work • More evaluation • The current result is based on a telephony prototype and simulation programs that developed in FLE • More qualitative and quantitative evaluation on different kinds of applications should be performed in future • Remaining problem • Exception scoping: limits the programs that the programmer have to examine when designing, debugging and changing the exception • How to limits the scope of exception while keeping the flexibility of exception handling.

47. www.openflx.com Click to edit company slogan . Thank You !