Exceptions exception handling mechanisms l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 116

Exceptions & Exception Handling Mechanisms PowerPoint PPT Presentation


  • 161 Views
  • Uploaded on
  • Presentation posted in: General

Exceptions & Exception Handling Mechanisms. Exceptions. Exceptions Definition Declaration Nature of exceptions. Exceptions. Definition Exceptions are unusual events or error conditions that occur during run time Such an event will result in a change of normal control flow.

Download Presentation

Exceptions & Exception Handling Mechanisms

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Exceptions exception handling mechanisms l.jpg

Exceptions&Exception Handling Mechanisms


Exceptions l.jpg

Exceptions

  • Exceptions

    • Definition

    • Declaration

    • Nature of exceptions


Exceptions3 l.jpg

Exceptions

  • Definition

    • Exceptions are unusual events or error conditions that occur during run time

    • Such an event will result in a change of normal control flow.

      • E.g. Failing to dial a prefix 9 in IIT telephone network while calling a number outside the IIT network.


Exceptions4 l.jpg

Exceptions

  • What events are unusual depends on the application and the situation that leads to those events

  • An exception in one case may not be so in another

    • E.g. Dialing prefix 9 in a telephone that is outside the IIT network.


Exceptions5 l.jpg

Exceptions

  • The severity of an exception also depends mostly on the application under consideration and the situation in which the exception has occurred.

    • E.g.

      • A wrong number in a telephone application will result only in a wrong call being placed.

      • But a wrong number in a life support system controller may end up fatal.


Exceptions6 l.jpg

Exceptions

  • So,

    • exact list of exceptions for an application is defined by the developer

    • that decision will be based on the application under consideration.


Exception declaration l.jpg

Exception Declaration

  • As any other object in the software paradigm there should be a way to represent exceptions

  • This has some important objectives,

    • Exceptions should be made explicit to the programmers so that they can consciously and cleverly utilize them in building robust applications.

    • The compiler will be able to aid the developers in various ways once they understand the exception objects, their type, binding, scope etc.


Exception declaration8 l.jpg

Exception declaration

  • To help programmers as we have mentioned above we need the following, at least.

    • Give each instance of each exception type a unique identification.

    • Once the exception has been identified, we need additional information about the cause of that exception

  • The requirements are not limited to just the list here.


Exception declaration9 l.jpg

Exception declaration

  • Exceptions are being represented in different ways. A few popular examples are,

    • Return value and flags

    • UNIX signals

    • Objects in OOP languages

  • We will examine each one of these mechanisms later in this presentation.


Nature of exceptions l.jpg

Nature of exceptions

  • Exception can be classified as

    • synchronous

    • asynchronous

    • user unaware

  • The above classification is from the aspect of the developer so that we can estimate how well one can be prepared to handle exceptions of the above categories.


Nature of exceptions11 l.jpg

Nature of exceptions

  • The synchronous ones are those that occur because of the actions of the execution in which they occur.

  • The executions are responsible for the exceptions that they have to face.

    • E.g. try-catch mechanism, return value indication.


Nature of exceptions12 l.jpg

Nature of exceptions

  • Asynchronous ones are those that occur in an execution different from the one where the exception is present. This occurs because of something not done by the execution that gets the exception. The exception is then propagated to the destination exception where it will be handled.

  • E.g. One thread stopping another thread using the signal mechanism


Nature of exceptions13 l.jpg

Nature of exceptions

  • User unaware exceptions:

    • A method calling another will not be aware of all the exceptions that could be thrown by the called method.

    • This problem plagued C++.

    • E.g.

      • If a developer has to use a class developed by someone else, he may not always have access to the source code.

      • All the developer can have for sure is the interface of that class. So there is no practical way he or the compiler can check and handle the exceptions thrown by that class or by another class used in that class.


Exception handling mechanisms l.jpg

Exception Handling Mechanisms

  • Exception Handling Mechanism

    • Purpose

    • Definition (What is EHM?)

    • Declaration

    • Nature of exception handling


Exception handling mechanism l.jpg

Exception Handling Mechanism

  • Why do we need exceptions and exception handling mechanism

    • Unusual events or errors are not uncommon in software products.

    • We have exceptions to address such events.

    • Having identified exceptions we need a way to process them.

    • The mechanism to process such exception events is called as Exception Handling Mechanism


Exception handling mechanisms16 l.jpg

Exception Handling Mechanisms

  • Exception handling is a programming language facility for the programmer to specify how an exception should be handled.

    • E.g.

      • try-catch mechanism in Java

      • Signal mechanism in Unix


Exception handling mechanisms17 l.jpg

Exception Handling Mechanisms

  • They (Exception Handlers) process the exceptions trying to recover from the error condition or to terminate in the best possible way.

    • Best possible way implies “minimal damage” to the state of the system under consideration.

      • Preserving the state variables


Exception handling mechanisms18 l.jpg

Exception Handling Mechanisms

  • The importance of EHM will be best understood by looking at the impact of a EHM on the resulting software products,

  • A poor exception handling mechanism might result in many or all of the following situations.

    • Reliability?

    • Stability?

    • Defining new exceptions?


Slide19 l.jpg

  • Code Tangling (Actual code and exception code)

    • Indecipherable code

    • Finding and fixing bugs will be difficult

    • Reverse engineering - a Herculean task.

    • Adding new software modules

    • Modifying existing software modules

    • Might result in code redundancy/duplication,

      • if the same exception needs to be handled in the same way in different parts of the program.


Nature of exception handling l.jpg

Nature of exception handling

  • Having discussed about the purpose and importance of exception handling, let us look at the choices we have in exception handling.

    • 1) Termination

    • 2) Retry

    • 3) Resume


Termination l.jpg

Termination.

  • First popular mechanism

  • The code after that point, at which an exception occurs, will not be executed.

    • i.e. the execution is terminated at the point at which an exception occurs

  • Once everything is done, in ideal case it will look as if the execution terminated normally just before the exception point as if the exception never occurred


Termination22 l.jpg

Termination.


Termination example l.jpg

Termination example

try {

buf = new char[512];

if( buf == 0 )

throw "Memory allocation failure!";

strycpy (buf, “This is a Test String”);

}

catch( char * str )

{

cout << "Exception raised: " << str << '\n';

}


Retry model l.jpg

Retry Model

  • In this model, the handler will try to clean up the environment resulted from the exception and will try to restart the execution.

  • The original environment at that point of execution should be restored.

    • This includes all the status flags, program counter etc.


Retry model25 l.jpg

Retry Model

  • So the environment should be stored each time the execution crosses a restart point, irrespective of whether there will be an exception or not.

  • This is obviously an additional overhead (this was not there in termination model)


Retry model26 l.jpg

Restart point

This part of the code will be executed again

Retry Model


Retry model restart point l.jpg

Retry model – restart point

  • Care should be taken while deciding the restart points.

  • If chosen too closely the overhead of saving the environment will be high.

  • If chosen too sparsely, when restarted from an exception too much of code will be repeated possibly resulting in more damage (like many files could have been changed etc) and poor performance.


Retry model restart point28 l.jpg

Retry model – restart point

  • In general the starting point of a guarded block will serve as the restart point

  • It could be logical too, depending on the application under consideration.

    • E.g. A bank may want to restart from a point where processing a record starts. This makes sense because starting somewhere else will result in partial processing of a record (if a new record is fetched to restart) or doing some part of the processing for a particular record twice (if the same record is used to restart).


Retry model e g using return value mechanism l.jpg

Retry model – E.g. using return value mechanism

main(int argc, char **argv)

{ …

int retry_count = MAX_RETRY;

while ( retry_count- -)

{

if ((hp = gethostbyname(hostname)) == 0)

{ perror("gethostbyname");

continue; } /* fill in the socket structure with host information */

if ((sd = socket(AF_INET, SOCK_STREAM, 0)) == -1)

{ perror("socket");

continue; } /* connect to PORT on HOST */

if (connect(sd,(struct sockaddr *) &pin, sizeof(pin)) == -1)

{ perror("connect");

close(sd);

continue; }

} //while

if (! retry_count) exit(1);

}//main


Resumption model l.jpg

Resumption Model

  • The handler does the work of cleaning up the damage resulted because of the exception

  • Then control is transferred to the point next to the one where the execution flow was interrupted because of the exception and the execution continues from there on.


Resumption model31 l.jpg

Resumption Model

  • the environment should be saved so that when the handler is done with its job, the control can be returned back to the point where the exception occurred.

  • When the control is returned a clean environment will be provided using the saved copy.


Resumption model32 l.jpg

Resumption Model

Exception point and restart point


Resumption model33 l.jpg

Resumption Model

  • One can say that the resume model is nothing but the retry model

    • the retry point is each line of code in the execution

    • i.e. after executing each line the environment should be saved


Resumption model e g using return value mechanism l.jpg

Resumption model – E.g. using return value mechanism

main(int argc, char **argv)

{ …

int retry_count = MAX_RETRY;

while ( retry_count- -)

{

if ((hp = gethostbyname(hostname)) == 0)

{ perror("gethostbyname");

continue; } /* fill in the socket structure with host information */

} //while

while ( retry_count- -)

{ if ((sd = socket(AF_INET, SOCK_STREAM, 0)) == -1)

{ perror("socket");

continue; } /* connect to PORT on HOST */

} //while

while ( retry_count- -)

{ if (connect(sd,(struct sockaddr *) &pin, sizeof(pin)) == -1)

{ perror("connect");

sleep(17);

continue; }

} //while

if (! retry_count) {close(sd); exit(1);}

}//main`


Resumption model35 l.jpg

Resumption Model

  • Though resume seems to be the best solution at hand, there are limitations. It does not resume exactly restoring everything.

    • E.g. if the source execution had incremented a counter in a file and while closing the file encountered an exception. The handler will not have enough knowledge to restore the counter in the file


Resumption model36 l.jpg

Resumption Model

  • Things like this cannot be fixed and might result in fatal damages depending on the situation.

  • Thus we can say that the EHM does not guarantee a complete recovery from an exception. It merely attempts to minimize the damage


Propagation mechanism l.jpg

Propagation mechanism

  • Responsible for delivering the exception to the correct handler

  • The propagation execution can be different from the source execution and the faulting execution

  • OR one of those two (source / faulting) can have the propagation functionality in itself.


Propagation mechanism38 l.jpg

Propagation mechanism

  • In order to deliver the exceptions at the correct destination, the propagation mechanism sometimes has additional work

    • E.g. Unwinding the stack while navigating up in the function call tree in try-catch mechanism


Propagation mechanism39 l.jpg

Propagation mechanism

  • Propagation mechanism can be one of the following,

    • Static

    • Dynamic

  • This classification is based on the way the destination is chosen by the propagation mechanism.


Static propagation l.jpg

Static propagation

  • In Static propagation the handler that will be used in a particular case will be known during compile time

  • A sequel has routines associated with it.

  • Exceptions are defined as sequels. When an exception is raised the sequel used to indicate that exception is called.


Static propagation41 l.jpg

Static propagation

  • This sequel is hard coded and the exception handler is available during compile time.

  • The sequel proposed by Tennent is an example of static propagation.


Static propagation example l.jpg

Static propagation - example

class stack

{

stack( sequel overflow(...) )

{ ... }

void push( int i )

{

...

raise overflow(...);

}

};

{

sequel StackOverflow(...)

{

...

}

stack s( StackOverflow );

...

s.push( 3 ); // causes overflow

}

The handler routine is passed as a parameter to the constructor

Exception Handler routine in this case


Dynamic propagation l.jpg

Dynamic propagation

  • The propagation model decides the handler to which the exception should be delivered.

  • The decision is made at run-time.

  • The decision usually depends on the type of exception thrown.

  • Most widely used

  • E.g. Java try-catch mechanism


Dynamic propagation44 l.jpg

Dynamic propagation

class stack

{

stack() { ... }

void push( int i )

{...

throw overflowexception;

...

throw generalStackException;

}

};

try{

stack s();

...

s.push( 3 ); // causes overflow

}

catch (OverflowException e ){

//handler1

}

catch(OtherStackException e){

//handler2 }

Handlers chosen depending on the exception


Existing exception handling mechanisms l.jpg

EXISTING EXCEPTION HANDLING MECHANISMS

  • Some of the today’s popular Exception Handling mechanisms,

    • Return value and flags

    • UNIX signal mechanism

    • Object oriented mechanism


Return value and flags l.jpg

Return value and flags

  • oldest exceptions handling mechanisms

  • still in use

  • exceptions are represented as numbers

  • value of the number decides the type of exception

  • numbers are usually return values of procedures.


Return value and flags47 l.jpg

Return value and flags

  • When procedures return control back to the caller they indicate any exception that may have occurred using the appropriate return values

  • The caller then checks the return value looking for any possible exceptions.


Return value and flags48 l.jpg

Return value and flags

  • In case of flags,

    • a flag is set to indicate error or exception.

    • The handler code is executed if a flag is set.

    • This is found by checking the flag bit whenever required.


Return value and flags49 l.jpg

Return value and flags

  • Problem with this mechanism

    • Multiple instances of an exception cannot be thrown

      • The second instance will overwrite the first by setting the respective flag

    • Numbers just convey the exception type

      • Does not carry any additional information


Return value and flags50 l.jpg

Return value and flags

  • Exception code and actual code are intermixed

  • One should check for all errors explicitly, a new error condition, requires changes in all calling programs.

  • All the developers will not have the same value for an exception i.e. no standard value for exception so not portable


Return value and flags example l.jpg

Return value and flags - example

  • int main(int argc,char **argv)

  • {

  • int s;

  • s = socket(PF_LOCAL,SOCK_DGRAM,0);

  • if ( s == -1 )

  • {

    • fprintf(stderr,"%s:socket(PF_LOCAL,SOCK_DGRAM,

    • 0)\n",strerror(errno));

  • return -1; /* Failed */

  • }

  • printf("s = %d;\n",s);

  • return 0;

  • }


Return value and flags example52 l.jpg

Return value and flags-example

  • Here the exception checking code is intermixed with the actual code.

  • As the complexity increases it would be very difficult to reverse engineer the code and get the actual program logic


Unix signal mechanism l.jpg

UNIX signal mechanism

  • exceptions are represented as signals

  • The signal doesn’t carry any additional information

  • Exception handling is done by the signal handlers

  • The handler can decide to terminate the execution

  • The control can be returned to a pre-determined retry point using some of the C language constructs (e.g. far jump)


Unix signal mechanism54 l.jpg

UNIX signal mechanism

  • The handler code in this case is separate from the actual code

  • Control is transferred to the handler code once the signal is received

    • After executing the handler, the control returns back to the actual code

    • Actual code  Handler  Actual code


Unix signal mechanism55 l.jpg

UNIX signal mechanism

  • The propagation mechanism here is responsible for delivering the signal

    • In this case the signals are actually software interrupts and hence the OS (operating system) takes care of delivering the signals.


Unix signal mechanism56 l.jpg

UNIX signal mechanism

  • Problems with this mechanism,

    • signals are again represented as numbers

    • A pending signal is represented using a single flag bit

      • so could be over-written by another instance of the same signal.

    • Limited number of signals

    • Each time after handling an exception, the handler should be associated to that signal explicitly


Unix signal mechanism57 l.jpg

UNIX signal mechanism

  • If different blocks have to handle the same exception with different handlers,

    • the new signal-handler association will replace the existing signal-handler association. The new handler should be good enough to call the first handler after completing its execution if both of them should be executed for an exception.


Unix signal mechanism example l.jpg

UNIX signal mechanism - example

// Exception Handler code

void signal_handler(int dummy) {

printf(“Arithmetic exception has occurred!\n”);

exit(1);

}

// Program code

int main()

{

int i=10, j=5;

// Register the handler

signal(SIGFPE, signal_handler);

printf(“Valid operation 10/5 = %d\n”,i/j);

j=0;

// Exception Divide-by-zero

printf(“Invalid operation 10/0 = %d\n”,i/j);

return 0;}

}

Exception handler & program code – separate


Object oriented mechanism l.jpg

Object oriented mechanism

  • exceptions are modeled as classes

  • each instance represented as objects of those classes

  • exceptions as objects also carry other information via its members.

    • For instance in Java, the exceptions can have a cause i.e. the exception that resulted in this exception thus creating a chain


Object oriented mechanism60 l.jpg

Object oriented mechanism

  • Inheritance

    • In Java, all the exceptions are subclasses of the throwable class giving all the exceptions certain basic functionalities

    • A parent child hierarchy of exceptions is created

    • The hierarchy tree has made possible the standardization of the exceptions.


Object oriented mechanism61 l.jpg

Object oriented mechanism

  • the execution throwing the exception is terminated

  • OOP provides dynamic propagation mechanism

    • They locate the handler dynamically during run-time depending on the exception thrown.

    • Stack is unwound until a matching handler is found

    • If no matching handler is found, usually the application will be terminated.


Object oriented mechanism62 l.jpg

Object oriented mechanism

  • Problems with this mechanism,

    • blocks of exception code and actual code are mixed up.

    • If the same handler is to be used in different places, code duplication is done

    • Adding new or changing existing exception handlers is difficult.

    • The try-catch mechanism requires the handlers in the order of the child-parent hierarchy.


Object oriented mechanism example l.jpg

Object oriented mechanism - example

public class EchoClient {

public static void main(String[] args) throws IOException {

Socket echoSocket = null;

PrintWriter out = null;

BufferedReader in = null;

try {

echoSocket = new Socket("valkyrie", 7);

out = new PrintWriter(echoSocket.getOutputStream(), true);

in = new BufferedReader(new InputStreamReader(

echoSocket.getInputStream()));

}

catch (UnknownHostException e) {

System.err.println("Don't know about host: valkyrie.");

System.exit(1);

}

catch (IOException e) {

System.err.println("Couldn't get I/O for "

+ "the connection to: valkyrie.");

System.exit(1);

}…}


Feature language extension l.jpg

Feature Language Extension


Feature language extension65 l.jpg

Feature Language Extension

  • Feature

    • A collection of small program units, offering a complete logical functionality of the application.

    • The developer defines the boundary of a feature depending on the requirement.

  • Problem

    • The above said Features interact i.e. modify each other’s behavior

    • Feature interaction results in dependencies between modules. One has to implement changes in all the interacting features to modify one feature.

    • This means that developer of one module has to depend on the developer of the other if both modules interact. The dependencies will shoot up rapidly with the size/complexity of the application under consideration. Most of the real time systems have many features that highly interact with each other.


Feature language extension66 l.jpg

Feature Language Extension

  • Impact of the problem in the software

    • Error prone since programmer is not most of the time sure if he has implemented the changes in all the required places.

    • Increasing cost for both development and maintenance

    • Because of this dependency of a feature on other features, it is not reusable.

    • There is no way one could analyze the features since the code for the features are tangled. i.e. they are not completely modularized as objects in OOP which would give us a better hold in automating the analysis of these software modules


Feature language extension67 l.jpg

Feature Language Extension

  • FLE remedies the problem

    • FLE attempts to remedy the above said problems. We know that feature interaction is the root cause of this dependency and hence the issue. Thus FLE targets on that and has come up with an extension where we modularize the interacting features and provide them (features) a clean mechanism to interact with each other by sending messages. These messages in FLE terms are the events.

    • Thus FLE avoids the code tangling issue and hence gives a clean interface between features.

    • Given with a clean interface developers can work with pre-agreed interfaces and don’t have to depend on developers of other features as long as they stick to the agreed interface.


Feature language extension68 l.jpg

Feature Language Extension

  • FLE model

    • FLE as the name says is an extension, of Java and in turn OOP.

    • One can visualize FLE as follows

Structured Programming

Object Oriented Programming

FLE Programming

(feature oriented)


Feature language extension69 l.jpg

Feature Language Extension

  • In structured programming the data and functions that operated on the data were not closely coupled or bonded. One passes the data to the functions and get them worked on.

  • In OOP we have modularization, as in the methods which will work on the data enclose the data thus providing a module of data and related methods to users and is called an object

  • Feature language can be viewed one more level of modularization where we use the OOP’s classes/objects and build features these features interact with each other using events in the same way objects interact in java using messages.

  • Refer to figure in the next slide


Feature illustration l.jpg

Feature illustration

Feature

Object

Data & Methods

Objects communicate with each other


Feature language extension71 l.jpg

Feature Language Extension

  • 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 and then works around that model

  • The model is composed of a domain statement

  • and a special feature called an anchor featurethat implements the basic functionalities of a component.


Feature language extension72 l.jpg

Feature Language Extension

  • 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.


Feature language extension73 l.jpg

Feature Language Extension

domain BasicTelephony {

variables:

DTenum State {DIALING, OUTPULSING, BUSY, AUDIBLE, TALKING, RINGING, DISCONNECT, IDLE};

State state= State.IDLE; // initial value

events:

TerminationRequest;

Busy;

Ringing;

Answer;

Disconnect;

Onhook;

Offhook;

Digits;

TimeOut;

}

  • Domain Statement

    • contains the definition of the condition variables,

      • domain variables

      • events


Feature language extension74 l.jpg

Feature Language Extension

anchor feature Pots {

domain BasicTelephony;

Phone fone;

Router rt;

public Pots (Phone fone, Router rt)

{ this.fone = fone;

this.rt = rt;

} // constructor for anchor feature Pots

MakeCall

{ condition: state.equals(State.IDLE);

event: Offhook;

{ fone.applyDialTone();

state = State.DIALING;

}

}…}

  • A Feature has the following

    • Program Unit

      • Condition Part

      • Body Part


Feature language extension75 l.jpg

Feature Language Extension

  • Correct program unit is executed depending on the event being sent and the condition part evaluating to be true.

  • When we have more than one program unit and/or features satisfying the criteria to be executed we need to resolve the precedence


Feature language extension example l.jpg

Feature Language Extension - example

feature DoNotDisturb {

domain BasicTelephony;

anchor POTS;

Router rt;

SayBusy {

condition: all;

event: TerminationRequest e; {

Busy b = new Busy();

rt.sendEvent (Event.FromPhoneID, b);

}

}

}


Feature language extension example77 l.jpg

Feature Language Extension - example

feature package QuietPhone {

domain: BasicTelephony;

Phone fone;

Router rt;

features: DoNotDisturb, POTS(fone, rt), CatchAll;

priorityPrecedence (DoNotDisturb, POTS, CatchAll);

// Constructor

public QuietPhone (Phone fone, Router rt) {

this.fone = fone ;

this.rt = rt ;

}

}


Fle s exception handling mechanism l.jpg

FLE’s Exception Handling Mechanism


Fle s exception handling mechanism79 l.jpg

FLE’s Exception Handling Mechanism

  • Exceptionsin FLE-EHM are special events called exception events

  • Events are represented as OOP classes.

  • There is a fine line of difference between the OOP exception objects and FLE exception events.

    • Events are represented as objects. Therefore all exception events are objects.

    • With some special properties related to exception handling.


Fle exceptions l.jpg

FLE – Exceptions

  • Exceptions are events?

    • Exceptions in reality are events. FLE takes the exception concept closer to real-life.

    • Takes advantage of the event driven language , FLE

  • New exceptions can be derived from the existing ones using inheritance


Fle exceptions81 l.jpg

FLE – Exceptions

  • FLE exceptions have all the advantages of Java exceptions.

  • They also have the advantages of the FLE events.

OOP Object

FLE Event

FLE Exception event


Fle exceptions82 l.jpg

FLE – Exceptions

  • All the exceptions thrown in a feature are listed in the domain statement

  • This is done for type checking, so that the FLE compiler will make sure that all the exceptions are handled.


Fle domain statement l.jpg

FLE – Domain statement

  • domain BasicTelephony {

  • variables:

  • DTenum State {DIALING, OUTPULSING, BUSY, AUDIBLE, TALKING,

  • RINGING, DISCONNECT, IDLE};

  • State state= State.IDLE; //initial value

  • events:

  • TerminationRequest;

  • Busy;

  • Ringing;

  • Onhook;

  • Offhook;

  • Digits;

  • exceptions:// The exceptions this feature

    • BindException// may throw are listed here.

      • ConnectException

    • MalformedURLException

    • I/OException;

    • Ringing_CircuitFailure;

  • AreaCode_Exception;

  • }


Fle exception handlers l.jpg

FLE – Exception handlers

  • The exception handlers are built in as exception program units

  • exception program units grouped as the exception features

    • These features can be added or removed in a single go


Slide86 l.jpg

  • exceptionFeatureDoNotDisturbException (FLException e)

  • {

  • domain BasicTelephony;

  • anchor pots;

  • /* Handler for someException */

  • catch_areaCodeException

  • {

  • condition: (evnt.fromAreaCode != 312)

  • OR (NOT poneBook.isKnown(e.fromPhoneId) )

  • AND state.equals(busy));

  • event: TerminationRequest evnt;

  • exception: areaCodeException e;

    • {

      • /* do exception handling , say print e.getStackTrace() */

    • }

  • }

  • /* Handler for phoneBookException */

  • Catch_phoneBookException

  • {

  • Context: onHold

  • Exception: phonebookException e

  • {

  • If(! fone.restoreBakup(e.phoneBook))

  • Throw phoneBookPermntDamageException;

  • Else /* EHM successful */

  • /* retry with the given context */

    • }

  • }

  • }


Fle exception handlers87 l.jpg

FLE – Exception handlers

  • The FLE compiler will check the exceptions that are listed in each feature package with those of the exception features available in the anchor feature.

  • If no exception feature has appropriate handler for a particular exception then a compiler error is thrown.

  • This helps programmer to ensure that all the exceptions are handled.


Fle exception handlers88 l.jpg

FLE – Exception handlers

  • When an exception is thrown, corresponding exception feature is found and the exception event is delivered.

  • The exception feature which has a matching program unit for the exception will consume the exception.

  • The uncaught exceptions are listed in the throws clause of the feature package.

    • We do this in feature package because feature package serves as an interface to the feature user who would not have any knowledge of the feature code.


Fle exception handlers89 l.jpg

FLE – Exception handlers

  • If many handlers need to handle an exception, using other exception program units then one of the following could be done,

    • Method calls like the following can be used to call an exception program unit.

    • Appropriate precedence list can pass the same exception to more than one handler in the specified order

    • The exception can be rethrown but in which case the exception will be sent out the immediate feature package and should be listed in the “throws” list of the feature package


Fle exception handlers90 l.jpg

FLE – Exception handlers

  • Method 3 in the above list falls in a slightly different – this can be used to passing the exception tonext level.

  • Though both method 1 and 2 are technically equivalent, method two (precedence) is recommended over the first for the following reasons,

    • Precedence list gives a clearer picture of the path of navigation for an exception than the method call style in which the “call” statement usually lies buried inside the program code.

    • It is easier and time saving to change the precedence list than the method call, if later one decides to change the control flow path.

    • Further discussion about precedence is in the later part of the presentation.


Exception handling model supported by fle l.jpg

Exception handling model supported by FLE

  • The FLE exception mechanism has provisions for

    • termination,

    • retry

    • resumption as well

  • Though resumption is possible at this stage we have not included resumption since the disadvantages outweigh the advantages in this model.


  • Exception handling model supported by fle92 l.jpg

    Exception handling model supported by FLE

    • Termination

      • The termination model will terminate the execution at the point of exception event and throws the exception event

      • The control is then transferred to event dispatcher i.e. the propagation mechanism

      • The exception is propagated to the matching handler


    Fle termination model l.jpg

    FLE – Termination model

    Exception Feature 1

    Feature 1

    Exception Feature 2

    Feature 2

    Event Dispatcher –

    FLE platform

    Feature n

    Exception Feature m

    Control flow during an exception in termination model


    Fle termination model94 l.jpg

    • feature DoNotDisturb (Phone fone, Router r) {

    • domain BasicTelephony;

    • anchorpots;

    • SayBusy {

    • condition: (evnt.fromAreaCode != 312) ;

    • event: TerminationRequest evnt; {

    • Busy b = new Busy();

    • If(!r.sendEvent (evnt.FromPhoneID, b))

    • throw AreaCode_Exception;

    • }

    • }

    • OnHold{

    • condition: (NOT poneBook.isKnown(e.fromPhoneId) )

      • AND state.equals(busy)

    • event: TerminationRequest evnt;{

    • Hold h = new Hold();

    • msg_id = phoneBook.getHoldMsg(evnt.fromPhoneId);

    • If(msg_id == EXCEPTION)

    • throw phoneBookException

    • If(msg_id != INVALID)

    • h.applyMsg(msg_id);

    • else

    • h.applyMsg(DEFAULT);

    • r.sendEvent(evnt.fromPhoneId, h)}

    FLE – Termination model


    Fle termination model95 l.jpg

    FLE – Termination model

    • exceptionFeatureDoNotDisturbException (FLException e)

    • {

    • domain BasicTelephony;

    • anchor pots;

    • /* Handler for someException */

    • catch_areaCodeException

    • {

    • condition: (evnt.fromAreaCode != 312)

    • OR (NOT poneBook.isKnown(e.fromPhoneId) )

    • AND state.equals(busy));

    • event: TerminationRequest evnt;

    • exception: areaCodeException e;

      • {

        • /* do exception handling , say print e.getStackTrace() */

      • }

    • }

    • /* Handler for phoneBookException */

    • Catch_phoneBookException

    • {

    • Context: onHold

    • Exception: phonebookException e

    • {

    • If(! fone.restoreBakup(e.phoneBook))

    • Throw phoneBookPermntDamageException;

    • Else /* EHM successful */

    • /* retry with the given context */

      • }

    • }

    • }


    Fle retry model l.jpg

    FLE – Retry Model

    • When an exception is encountered, control will be transferred to the handler.

    • The handler does the work and at the end will resend the event that led to the exception.

    • This will transfer control to the same program unit where the exception occurred.


    Fle retry model97 l.jpg

    FLE – Retry Model

    Exception Feature 1

    Feature 1

    Exception Feature 2

    Feature 2

    Event Dispatcher –

    FLE platform

    Feature n

    Exception Feature m

    Control flow during an exception in retry model


    Fle retry model98 l.jpg

    FLE –Retry model

    • exceptionFeatureDoNotDisturbException (FLException e)

    • {

    • domain BasicTelephony;

    • anchor pots;

    • /* Handler for someException */

    • catch_areaCodeException

    • {

    • condition: (evnt.fromAreaCode != 312)

    • OR (NOT poneBook.isKnown(e.fromPhoneId) )

    • AND state.equals(busy));

    • event: TerminationRequest evnt;

    • exception: areaCodeException e;

      • {

        • /* do exception handling , say print e.getStackTrace() */

    • pots.sendevent(TerminationRequest evnt)

    • /* this helps retrying the execution */

      • }

    • }


    Propagation mechanism in fle ehm l.jpg

    Propagation mechanism in FLE-EHM

    • Exception is delivered to the appropriate handler by the propagation mechanism.

    • The propagation mechanism uses the exception type and the context of the raise point to decide the handler to which the exception will be delivered

    • When there is more than one matching handler the propagation mechanism uses the precedence list


    Propagation mechanism in fle ehm100 l.jpg

    Propagation mechanism in FLE-EHM

    • There are two types of precedence namely

      • priority precedence and

      • straight precedence.

    • In priority precedence the first matching handler will be executed.

    • In straightprecedence all the matching handlers will be executed in the given order of priority.


    Propagation mechanism in fle ehm101 l.jpg

    Propagation mechanism in FLE-EHM

    • To address other priority requirements,

      • We use a Hybrid or mixed priority which is formed as a combination of the above two lists

    • This list will be able to address all the required combinations to list the priority.


    Propagation mechanism in fle ehm102 l.jpg

    Propagation mechanism in FLE-EHM

    Priority Precedence

    priorityPrecedence(feature1, feature2, feature3); - In this example the exception event will be consumed by the first matching feature.

    Straight Precedence

    straightPrecedence(feature1,feature2, feature3);– Here the exception event will be delivered to all the features and the matching features will process the exception in the order listed.

    Mixed Precedence

    Straightprecedence( priorityPecedence(feature1, feature2), feature3,feature4);- In this example the exception event will be delivered to the first matching feature among feature1 and feature2. Then it will also be delivered to feature3 and feature4. But feature3 and/or feature4 will process the exception only if there is a match.


    Propagation mechanism in fle ehm103 l.jpg

    Propagation mechanism in FLE-EHM

    • Though the precedence list is a language semantics it is as important as any other component of a programming language.


    Advantages of fle ehm l.jpg

    Advantages of FLE-EHM

    • Separation of concern


    Advantages of fle ehm106 l.jpg

    Advantages of FLE-EHM

    • Not only exceptions but exception handlers can be reused.

    • Java has not included the so called run-time exceptions in its exception checking mechanism. This is because the founders of Java felt that it will be too much of a trouble for a programmer to handle all the exceptions especially the numerous run-time exceptions (e.g. divide by zero etc.).

      • In FLE since handlers can be reused, a developer can include default handlers for all the common exceptions during compilation and so FLE can be made to check for all the exceptions without adding burden to the developers.


    Advantages of fle ehm107 l.jpg

    Advantages of FLE-EHM

    • The FLE’s precedence mechanism provides an elegant way to override the default handlers for specific exceptions.

      • So the developer can use general handlers to handle all but a few exceptions for which he can have his own handlers.

    • Development is made easier. Once the exceptions are clearly defined then different developers can work on the program and exception handlers without depending on each other.

    • It will be much easier to upgrade either the program part or exception handling part as and when required.


    Advantages of fle ehm108 l.jpg

    Advantages of FLE-EHM

    • Middle-ware independent exception handling

      • Using feature language if one has to implement a soft-phone application, this can be done using sockets or RMI. Depending on this choice the exception handling code will change too.

      • But in FLE one can have exception code for both RMI and sockets and can just add the one that they need and compile.

      • Changing the above will be as simple as removing the existing feature and adding the required one in just a single go. We do not have to search and change code throughout the program.


    Advantages of fle ehm middle ware independent exception handling l.jpg

    Soft phone application feature

    RMI exception feature

    Feature available

    Socket exception feature

    Feature Package 1

    Feature Package 2

    Soft phone application feature

    Soft phone application feature

    Socket exception feature

    RMI exception feature

    Advantages of FLE-EHM Middle-ware independent exception handling


    Advantages of fle ehm110 l.jpg

    Advantages of FLE-EHM

    • Exception Reuse

      • The exceptions can be reused unlike the return value or the signal mechanism.

      • A standard library of exception can be built and this will save development time of standard exception handling features


    Advantages of fle ehm111 l.jpg

    Advantages of FLE-EHM

    • Exception handler reuse

      • Exception handlers can also be reused. This feature is not supported by Java.

      • Exception handler libraries can be created. Handlers can be included by merely adding them to the exception feature package and compiling them.


    Advantages of fle ehm112 l.jpg

    Advantages of FLE-EHM

    • If we decide to work on exception handling after completing the actual code we need to make certain compromises in Java.

      • In java, we have to specify all the exceptions in the throws list and then at the outer most blocks those exceptions should be handled.

      • After completing the actual code we have to dig into the code to add the exception handlers.

      • In FLE we can have a catchall handler in the beginning which will handle all the exceptions. Once we are done with the actual code then we can build the handlers and add them to the exception feature. We do not have to modify the actual code at all.


    Advantages of fle ehm113 l.jpg

    Advantages of FLE-EHM

    • The precedence list in the exception feature gives developers the flexibility to change to handlers or the order of execution by simply changing the precedence list.

    • Since exceptions are modeled as objects, they carry valuable additional information to the handlers.

    • Re-throwing exceptions is also made possible in a simple way. The handlers have to throw a new exception or have to re-thrown the actual exception.

      • Developers have to provide appropriate handlers to handle such exceptions.


    Code generation compiler l.jpg

    Code generation / compiler

    • FLE programs are compiled using the following tools

      • Java Compiler Compiler (JavaCC)

      • Java Tree Builder (JTB)


  • Login