In this Session XI : Exception Handling and Event Handling there are 5 subtopics:

• Introduction to Exception Handling
• Exception Handling in C++
• Introduction to Event Handling
• Event Handling with Java
• Event Handling in C#

Introduction to Exception Handling

Most computer hardware systems are capable of detecting certain run-time error conditions, such as floating-point overflow. Early programming languages were designed and implemented in such a way that the user program could neither detect nor attempt to deal with such errors. In these languages, the occurrence of such an error simply causes the program to be terminated and control to be transferred to the operating system. The typical operating system reaction to a run-time error is to display a diagnostic message, which may be meaningful and therefore useful, or highly cryptic. After displaying the message, the program is terminated. In a language with exception handling, programs are allowed to trap some exceptions, thereby providing the possibility of fixing the problem and continuing

Exception is any unusual event, erroneous or not, that is detectable by either hardware or software and that may require special processing. The special processing that may be required when an exception is detected is called exception handling. This processing is done by a code unit or segment called an exception handler.  An exception is raised when its associated event occurs. A language that does not have exception handling capabilities can still define, detect, raise, and handle exceptions (user defined, software detected)

Advantages of Built-in Exception Handling:

• Error detection code is tedious to write and it clutters the program
• Exception handling encourages programmers to consider many different possible errors
• Exception propagation allows a high level of reuse of exception handling code

Exception Handling Control Flow

Exception Handling in C++

The exception handling of C++ was accepted by the ANSI C++ standardization committee in 1990 and subsequently found its way into C++ implementations. The design is based in part on the exception handling of CLU, Ada, and ML.

C++ uses a special construct that is introduced with the reserved word try for this purpose. A try construct includes a compound statement called the try clause and a list of exception handlers. The compound statement defines the scope of the following handlers.

Each catch function is an exception handler. A catch function can have only a single formal parameter, which is similar to a formal parameter in a function definition in C++, including the possibility of it being an ellipsis (. . .). A handler with an ellipsis formal parameter is the catch-all handler; it is enacted for any raised exception if no appropriate handler was found.

The formal parameter need not have a variable, it can be simply a type name to distinguish the handler it is in from others. The formal parameter can be used to transfer information to the handler and be an ellipsis, in which case it handles all exceptions not yet handled.

C++ design is quite different: There are no predefined hardware-detectable exceptions that can be handled by the user, and exceptions are not named. Exceptions are connected to handlers through a parameter type in which the formal parameter may be omitted. The type of the formal parameter of a handler determines the condition under which it is called but may have nothing whatsoever to do with the nature of the raised exception. Therefore, the use of predefined types for exceptions certainly does not promote readability. It is much better to define classes for exceptions with meaningful names in a meaningful hierarchy that can be used for defining exceptions. The exception parameter provides a way to pass information about an exception to the exception handler.

Introduction to Event Handling

Event handling is similar to exception handling. In both cases, the handlers are implicitly called by the occurrence of something, either an exception or an event. While exceptions can be created either explicitly by user code or implicitly by hardware or a software interpreter, events are created by external actions, such as user interactions through a graphical user interface (GUI). In this section, the fundamentals of event handling, which are substantially less complex than those of exception handling, are introduced. An event is a notification that something specific has occurred, such as a mouse click on a graphical button, the event handler is a segment of code that is executed in response to an event

Event Handling with Java

Java Swing GUI Components

Text box is an object of class JTextField. Radio button is an object of class JRadioButton. Applet’s display is a frame, a multilayered structure. Content pane is one layer, where applets put output. GUI components can be placed in a frame. Layout manager objects are used to control the placement of components.

The Java Event Model

When a user interacts with a GUI component, for example by clicking a button, the component creates an event object and calls an event handler through an object called an event listener, passing the event object. The event handler provides the associated actions. GUI components are event generators; they generate events. In Java, events are connected to event handlers through event listeners. Event listeners are connected to event generators through event listener registration. Listener registration is done with a method of the class that implements the listener interface, as described later in this section. Only event listeners that are registered for a specific event are notified when that event occurs.

One class of events is ItemEvent, which is associated with the event of clicking a checkbox, a radio button, or a list item. The ItemListener interface prescribes a method, itemStateChanged, which is a handler for ItemEvent events, the listener is created with addItemListener.

Event Handling in C#

Event handling in C# (and in the other .NET languages) is similar to that of Java. .NET provides two approaches to creating GUIs in applications, the original Windows Forms and the more recent Windows Presentation Foundation.

Using Windows Forms, a C# application that constructs a GUI is created by subclassing the Form predefined class, which is defined in the System.Windows .Forms namespace. This class implicitly provides a window to contain our components. There is no need to build frames or panels explicitly. Text can be placed in a Label object and radio buttons are objects of the RadioButton class. The size of a Label object is not explicitly specified in the constructor; rather it can be specified by setting the AutoSize data member of the Label object to true, which sets the size according to what is placed in it. Components can be placed at a particular location in the window by assigning a new Point object to the Location property of the component. The Point class is defined in the System.Drawing namespace. The Point constructor takes two parameters, which are the coordinates of the object in pixels.

An event handler can have any name, a radio button is tested with the Boolean Checked property of the button and to register an event, a new EventHandler object must be created and added to  the predefined delegate for the event

When a radio button changes from unchecked to checked, the CheckedChanged event is raised, the associated delegate is referenced by the name of the event.