How can do Exception Handling in Pl/SQL ?

In this section we will discuss about the following,
1) What is Exception Handling.
2) Structure of Exception Handling.
3) Types of Exception Handling.
1) What is Exception Handling?

PL/SQL provides a feature to handle the Exceptions which occur in a PL/SQL Block known as exception Handling. Using Exception Handling we can test the code and avoid it from exiting abruptly. When an exception occurs a messages which explains its cause is recieved.
PL/SQL Exception message consists of three parts.
1) Type of Exception
2) An Error Code
3) A message
By Handling the exceptions we can ensure a PL/SQL block does not exit abruptly.
2) Structure of Exception Handling.

The General Syntax for coding the exception section

 DECLARE

   Declaration section

 BEGIN

   Exception section

 EXCEPTION

 WHEN ex_name1 THEN

    -Error handling statements

 WHEN ex_name2 THEN

    -Error handling statements

 WHEN Others THEN

   -Error handling statements

END;

General PL/SQL statments can be used in the Exception Block.

When an exception is raised, Oracle searches for an appropriate exception handler in the exception section. For example in the above example, if the error raised is 'ex_name1 ', then the error is handled according to the statements under it. Since, it is not possible to determine all the possible runtime errors during testing fo the code, the 'WHEN Others' exception is used to manage the exceptions that are not explicitly handled. Only one exception can be raised in a Block and the control does not return to the Execution Section after the error is handled.

If there are nested PL/SQL blocks like this.

 DELCARE

   Declaration section

 BEGIN

    DECLARE

      Declaration section

    BEGIN

      Execution section

    EXCEPTION

      Exception section

    END;

 EXCEPTION

   Exception section

 END;

In the above case, if the exception is raised in the inner block it should be handled in the exception block of the inner PL/SQL block else the control moves to the Exception block of the next upper PL/SQL Block. If none of the blocks handle the exception the program ends abruptly with an error.
3) Types of Exception.

There are 3 types of Exceptions.
a) Named System Exceptions
b) Unnamed System Exceptions
c) User-defined Exceptions
a) Named System Exceptions

System exceptions are automatically raised by Oracle, when a program violates a RDBMS rule. There are some system exceptions which are raised frequently, so they are pre-defined and given a name in Oracle which are known as Named System Exceptions.

For example: NO_DATA_FOUND and ZERO_DIVIDE are called Named System exceptions.

Named system exceptions are:
1) Not Declared explicitly,
2) Raised implicitly when a predefined Oracle error occurs,
3) caught by referencing the standard name within an exception-handling routine.
Exception Name     Reason     Error Number

CURSOR_ALREADY_OPEN
   

When you open a cursor that is already open.
   

ORA-06511

INVALID_CURSOR
   

When you perform an invalid operation on a cursor like closing a cursor, fetch data from a cursor that is not opened.
   

ORA-01001

NO_DATA_FOUND
   

When a SELECT...INTO clause does not return any row from a table.
   

ORA-01403

TOO_MANY_ROWS
   

When you SELECT or fetch more than one row into a record or variable.
   

ORA-01422

ZERO_DIVIDE
   

When you attempt to divide a number by zero.
   

ORA-01476

For Example: Suppose a NO_DATA_FOUND exception is raised in a proc, we can write a code to handle the exception as given below.

BEGIN

  Execution section

EXCEPTION

WHEN NO_DATA_FOUND THEN

 dbms_output.put_line ('A SELECT...INTO did not return any row.');

 END;

b) Unnamed System Exceptions

Those system exception for which oracle does not provide a name is known as unamed system exception. These exception do not occur frequently. These Exceptions have a code and an associated message.

There are two ways to handle unnamed sysyem exceptions:
1. By using the WHEN OTHERS exception handler, or
2. By associating the exception code to a name and using it as a named exception.

We can assign a name to unnamed system exceptions using a Pragma called EXCEPTION_INIT.
EXCEPTION_INIT will associate a predefined Oracle error number to a programmer_defined exception name.

Steps to be followed to use unnamed system exceptions are
• They are raised implicitly.
• If they are not handled in WHEN Others they must be handled explicity.
• To handle the exception explicity, they must be declared using Pragma EXCEPTION_INIT as given above and handled referecing the user-defined exception name in the exception section.

The general syntax to declare unnamed system exception using EXCEPTION_INIT is:

DECLARE

   exception_name EXCEPTION;

   PRAGMA

   EXCEPTION_INIT (exception_name, Err_code);

BEGIN

Execution section

EXCEPTION

  WHEN exception_name THEN

     handle the exception

END;

For Example: Lets consider the product table and order_items table from sql joins.

Here product_id is a primary key in product table and a foreign key in order_items table.
If we try to delete a product_id from the product table when it has child records in order_id table an exception will be thrown with oracle code number -2292.
We can provide a name to this exception and handle it in the exception section as given below.

 DECLARE

  Child_rec_exception EXCEPTION;

  PRAGMA

   EXCEPTION_INIT (Child_rec_exception, -2292);

BEGIN

  Delete FROM product where product_id= 104;

EXCEPTION

   WHEN Child_rec_exception

   THEN Dbms_output.put_line('Child records are present for this product_id.');

END;

/

c) User-defined Exceptions

Apart from sytem exceptions we can explicity define exceptions based on business rules. These are known as user-defined exceptions.

Steps to be followed to use user-defined exceptions:
• They should be explicitly declared in the declaration section.
• They should be explicitly raised in the Execution Section.
• They should be handled by referencing the user-defined exception name in the exception section.

For Example: Lets consider the product table and order_items table from sql joins to explain user-defined exception.
Lets create a business rule that if the total no of units of any particular product sold is more than 20, then it is a huge quantity and a special discount should be provided.

DECLARE

  huge_quantity EXCEPTION;

  CURSOR product_quantity is

  SELECT p.product_name as name, sum(o.total_units) as units

  FROM order_tems o, product p

  WHERE o.product_id = p.product_id;

  quantity order_tems.total_units%type;

  up_limit CONSTANT order_tems.total_units%type := 20;

  message VARCHAR2(50);

BEGIN

  FOR product_rec in product_quantity LOOP

    quantity := product_rec.units;

     IF quantity > up_limit THEN

      message := 'The number of units of product ' || product_rec.name || 

                 ' is more than 20. Special discounts should be provided.

         Rest of the records are skipped. '

     RAISE huge_quantity;

     ELSIF quantity < up_limit THEN

      v_message:= 'The number of unit is below the discount limit.';

     END IF;

     dbms_output.put_line (message);

  END LOOP;

 EXCEPTION

   WHEN huge_quantity THEN

     dbms_output.put_line (message);

 END;

/

RAISE_APPLICATION_ERROR ( )

RAISE_APPLICATION_ERROR is a built-in procedure in oracle which is used to display the user-defined error messages along with the error number whose range is in between -20000 and -20999.

Whenever a message is displayed using RAISE_APPLICATION_ERROR, all previous transactions which are not committed within the PL/SQL Block are rolled back automatically (i.e. change due to INSERT, UPDATE, or DELETE statements).

RAISE_APPLICATION_ERROR raises an exception but does not handle it.

RAISE_APPLICATION_ERROR is used for the following reasons,
a) to create a unique id for an user-defined exception.
b) to make the user-defined exception look like an Oracle error.

The General Syntax to use this procedure is:

RAISE_APPLICATION_ERROR (error_number, error_message);


• The Error number must be between -20000 and -20999
• The Error_message is the message you want to display when the error occurs.

Steps to be folowed to use RAISE_APPLICATION_ERROR procedure:
1. Declare a user-defined exception in the declaration section.
2. Raise the user-defined exception based on a specific business rule in the execution section.
3. Finally, catch the exception and link the exception to a user-defined error number in RAISE_APPLICATION_ERROR.

Using the above example we can display a error message using RAISE_APPLICATION_ERROR.

DECLARE

  huge_quantity EXCEPTION;

  CURSOR product_quantity is

  SELECT p.product_name as name, sum(o.total_units) as units

  FROM order_tems o, product p

  WHERE o.product_id = p.product_id;

  quantity order_tems.total_units%type;

  up_limit CONSTANT order_tems.total_units%type := 20;

  message VARCHAR2(50);

BEGIN

  FOR product_rec in product_quantity LOOP

    quantity := product_rec.units;

     IF quantity > up_limit THEN

        RAISE huge_quantity;

     ELSIF quantity < up_limit THEN

      v_message:= 'The number of unit is below the discount limit.';

     END IF;

     Dbms_output.put_line (message);

  END LOOP;

 EXCEPTION

   WHEN huge_quantity THEN

    raise_application_error(-2100, 'The number of unit is above the discount limit.');

 END;

/

What are Cursors?

A cursor is a temporary work area created in the system memory when a SQL statement is executed. A cursor contains information on a select statement and the rows of data accessed by it. This temporary work area is used to store the data retrieved from the database, and manipulate this data. A cursor can hold more than one row, but can process only one row at a time. The set of rows the cursor holds is called the active set.

There are two types of cursors in PL/SQL:
Implicit cursors:

These are created by default when DML statements like, INSERT, UPDATE, and DELETE statements are executed. They are also created when a SELECT statement that returns just one row is executed.
Explicit cursors:

They must be created when you are executing a SELECT statement that returns more than one row. Even though the cursor stores multiple records, only one record can be processed at a time, which is called as current row. When you fetch a row the current row position moves to next row.
Both implicit and explicit cursors have the same functionality, but they differ in the way they are accessed.

Implicit Cursors:

When you execute DML statements like DELETE, INSERT, UPDATE and SELECT statements, implicit statements are created to process these statements.
Oracle provides few attributes called as implicit cursor attributes to check the status of DML operations. The cursor attributes available are %FOUND, %NOTFOUND, %ROWCOUNT, and %ISOPEN.
For example, When you execute INSERT, UPDATE, or DELETE statements the cursor attributes tell us whether any rows are affected and how many have been affected.
When a SELECT... INTO statement is executed in a PL/SQL Block, implicit cursor attributes can be used to find out whether any row has been returned by the SELECT statement. PL/SQL returns an error when no data is selected.
The status of the cursor for each of these attributes are defined in the below table. 

Attributes	Return Value	Example
%FOUND	The return value is TRUE, if the DML statements like INSERT, DELETE and UPDATE affect at least one row and if SELECT ….INTO statement return at least one row.	SQL%FOUND
	The return value is FALSE, if DML statements like INSERT, DELETE and UPDATE do not affect row and if SELECT….INTO statement do not return a row.
%NOTFOUND	The return value is FALSE, if DML statements like INSERT, DELETE and UPDATE at least one row and if SELECT ….INTO statement return at least one row.	SQL%NOTFOUND
	The return value is TRUE, if a DML statement like INSERT, DELETE and UPDATE do not affect even one row and if SELECT ….INTO statement does not return a row.
%ROWCOUNT	Return the number of rows affected by the DML operations INSERT, DELETE, UPDATE, SELECT	SQL%ROWCOUNT

For Example: Consider the PL/SQL Block that uses implicit cursor attributes as shown below:

DECLARE  var_rows number(5);

BEGIN

UPDATE employee 

SET salary = salary + 1000;

IF SQL%NOTFOUND THEN

dbms_output.put_line('None of the salaries where updated');

ELSIF SQL%FOUND THEN

var_rows := SQL%ROWCOUNT;

dbms_output.put_line('Salaries for ' || var_rows || 'employees are updated');

END IF; 

END; 

In the above PL/SQL Block, the salaries of all the employees in the ‘employee’ table are updated. If none of the employee’s salary are updated we get a message 'None of the salaries where updated'. Else we get a message like for example, 'Salaries for 1000 employees are updated' if there are 1000 rows in ‘employee’ table.

How to pass parameters to Procedures and Functions in PL/SQL ?

In PL/SQL, we can pass parameters to procedures and functions in three ways.

1) IN type parameter: These types of parameters are used to send values to stored procedures.
2) OUT type parameter: These types of parameters are used to get values from stored procedures. This is similar to a return type in functions.
3) IN OUT parameter: These types of parameters are used to send values and get values from stored procedures.

NOTE: If a parameter is not explicitly defined a parameter type, then by default it is an IN type parameter.

1) IN parameter:

This is similar to passing parameters in programming languages. We can pass values to the stored procedure through these parameters or variables. This type of parameter is a read only parameter. We can assign the value of IN type parameter to a variable or use it in a query, but we cannot change its value inside the procedure.

The General syntax to pass a IN parameter is

CREATE [OR REPLACE] PROCEDURE procedure_name (

  param_name1 IN datatype, param_name12 IN datatype ... )

    param_name1, param_name2... are unique parameter names.
    datatype - defines the datatype of the variable.
    IN - is optional, by default it is a IN type parameter.


2) OUT Parameter:

The OUT parameters are used to send the OUTPUT from a procedure or a function. This is a write-only parameter i.e, we cannot pass values to OUT paramters while executing the stored procedure, but we can assign values to OUT parameter inside the stored procedure and the calling program can recieve this output value.

The General syntax to create an OUT parameter is

CREATE [OR REPLACE] PROCEDURE proc2 (param_name OUT datatype)

The parameter should be explicity declared as OUT parameter.

3) IN OUT Parameter:

The IN OUT parameter allows us to pass values into a procedure and get output values from the procedure. This parameter is used if the value of the IN parameter can be changed in the calling program.

By using IN OUT parameter we can pass values into a parameter and return a value to the calling program using the same parameter. But this is possible only if the value passed to the procedure and output value have a same datatype. This parameter is used if the value of the parameter will be changed in the procedure.

The General syntax to create an IN OUT parameter is

CREATE [OR REPLACE] PROCEDURE proc3 (param_name IN OUT datatype)


The below examples show how to create stored procedures using the above three types of parameters.

Example1:

Using IN and OUT parameter:

Let’s create a procedure which gets the name of the employee when the employee id is passed.

1> CREATE OR REPLACE PROCEDURE emp_name (id IN NUMBER, emp_name OUT NUMBER)

2> IS

3> BEGIN

4>    SELECT first_name INTO emp_name

5>    FROM emp_tbl WHERE empID = id;

6> END;

7> /

We can call the procedure ‘emp_name’ in this way from a PL/SQL Block.

1> DECLARE

2>  empName varchar(20);

3>  CURSOR id_cur SELECT id FROM emp_ids;

4> BEGIN

5> FOR emp_rec in id_cur

6> LOOP

7>   emp_name(emp_rec.id, empName);

8>   dbms_output.putline('The employee ' || empName || ' has id ' || emp-rec.id);

9> END LOOP;

10> END;

11> /

In the above PL/SQL Block
In line no 3; we are creating a cursor ‘id_cur’ which contains the employee id.
In line no 7; we are calling the procedure ‘emp_name’, we are passing the ‘id’ as IN parameter and ‘empName’ as OUT parameter.
In line no 8; we are displaying the id and the employee name which we got from the procedure ‘emp_name’.

Example 2:

Using IN OUT parameter in procedures:

1> CREATE OR REPLACE PROCEDURE emp_salary_increase

2> (emp_id IN emptbl.empID%type, salary_inc IN OUT emptbl.salary%type)

3> IS

4>    tmp_sal number;

5> BEGIN

6>    SELECT salary

7>    INTO tmp_sal

8>    FROM emp_tbl

9>    WHERE empID = emp_id;

10>   IF tmp_sal between 10000 and 20000 THEN

11>      salary_inout := tmp_sal * 1.2;

12>   ELSIF tmp_sal between 20000 and 30000 THEN

13>      salary_inout := tmp_sal * 1.3;

14>   ELSIF tmp_sal > 30000 THEN

15>      salary_inout := tmp_sal * 1.4;

16>   END IF;

17> END;

18> /

The below PL/SQL block shows how to execute the above 'emp_salary_increase' procedure.

1> DECLARE

2>    CURSOR updated_sal is

3>    SELECT empID,salary

4>    FROM emp_tbl;

5>    pre_sal number;

6> BEGIN

7>   FOR emp_rec IN updated_sal LOOP

8>       pre_sal := emp_rec.salary;

9>       emp_salary_increase(emp_rec.empID, emp_rec.salary);

10>       dbms_output.put_line('The salary of ' || emp_rec.empID ||

11>                ' increased from '|| pre_sal || ' to '||emp_rec.salary);

12>   END LOOP;

13> END;

14> /

Briefly explain key features of the JavaServer Faces (JSF) framework?

JavaServer Faces is a new framework for building Web applications using Java. JSF provides you with the

following main features:

􀂃

viewer, query builder etc. JSF was built with a

support Rapid Application Development (RAD). User interfaces can be created from these reusable serverside

components.

Basic user interface components like buttons, input fields, links etc. and custom components like tree/tablecomponent model in mind to allow tool developers to

􀂃

custom components.

Provides a set of JSP tags to access interface components. Also provides a framework for implementing

􀂃

event handling and component rendering. There is a single controller servlet every request goes through

where the job of the controller servlet is to receive a faces page with components and then fire off events

for each component to render the components using a render tool kit.

Supports mark up languages other than HTML like WML (Wireless Markup Language) by encapsulating

􀂃

faces-config.xml . This configuration file also defines bean resources used by JSF.

Uses a declarative navigation model by defining the navigation rules inside the XML configuration file

􀂃

JSF can hook into your model, which means the model is loosely coupled from JSF.

JavaServer Faces application structure

Web

WEB-INF

JSPs

classes

lib

jsf-api.jar

faces-config.xml

jsf-impl.jar

web.xml

input_accountNumber.jsp

output_accountNumber.jsp

AccountBean.class

Let’s look at some code snippets. Texts are stored in a properties file called

properties file can be quickly modified without having to modify the JSPs and also more maintainable because

multiple JSP pages can use the same property.

message.properties so that this

account_nuber = Account number

account_button = Get account details

account_message=Processing account number :

input_accountNumber.jsp

<%@ taglib uri="http://java.sun.com.jsf/html" prefix="h" %>

<%@ taglib uri="http://java.sun.com.jsf/core" prefix="f" %>

<f:loadBundle basename="messages" var="msg"/>

<html>

...

<body>

<f:view>

<h:form id="accountForm">

<h:outputText value="#{msg.account_number}" />

<

<h:commandButton action="getAccount" value="#{msg.account_button}" />

</h:form>

</f:view>

</body>

</html>

h:inputText value="#{accountBean.accountNumber}" />

AccountBean.Java

public class AccountBean {

String accountNumber;

Emerging Technologies/Frameworks…

341

public String getAccountNumber() {

return accountNumber;

}

public void setAccountNumber(String accountNumber) {

this.accountNumber = accountNumber;

}

}

faces-config.xml

...

<faces-config>

<navigation-rule>

<form-view-id>/jsps/input_accountNumber.jsp</form-view-id>

<navigation-case>

<from-outcome>getAccount</from-outcome>

<to-view-id>/jsps/output_accountNumber.jsp</to-view-id>

</navigation-case>

</navigation-rule>

...

<managed-bean>

<managed-bean-name>accountBean</managed-bean-name>

<managed-bean-class>AccountBean</managed-bean-class>

<managed-bean-scope>request</managed-bean-scope>

</managed-bean>

</faces-config>

output_accountNumber.jsp

<html>

...

<body>

<f:view>

<h3>

<h:outputText value="#{msg.account_message}" />

<

</h3>

</f:view>

</body>

</html>

h:outputText value="#{accountBean.accountNumber}" />

What purpose does the Cloneable interface serve ?

When JVM sees a clone() method being invoked on an object, it first verifies if the underlying class has implemented the 'Cloneable' interface or not. If not, then it throws the exception CloneNotSupportedException. Assuming the underlying class has implemented the 'Cloneable' interface, JVM does some internal work (maybe by calling some method) to facilitate the cloning operation. Cloneable is a marker interface and having no behavior declared in it for the implementing class to define because the behavior is to be supported by JVM and not the implementing classes (maybe because it's too tricky, generic, or low-level at the implementing class level). So, effectively marker interfaces kind of send out a signal to the corresponding external/internal entity (JVM in case of Cloneable) for them to arrange for the necessary functionality.

How does JVM support the 'cloning' functionality - probably by using a native method call as cloning mechanism involves some low-level tasks which are probably not possible with using a direct Java method. So, a possible 'Object.clone' implementation would be something like this:-

public Object clone() throws CloneNotSupportedException {

 if (this implements Cloneable)

     return nativeCloneImpl();

 else

     throw new CloneNotSupportedException();

}

Anyone wondered as to why and when do we get 'CloneNotSupportedException' exception at compile-time itself? Well... that's no trick. If you see the signature of the 'Object.clone()' method carefully, you will see a throws clause associated with it. I'm sure how can you get rid of it: (i) by wrapping the clone-invocation code within appropriate try-catch (ii) throwing the CloneNotSupportedException from the calling method.

What purpose does a user-defined marker interface serve? It can well serve the same purpose as by any standard marker interface, but in that case the container (the module controlling the execution of the app) has to take the onus of making sure that whenever a class implements that interface it does the required work to support the underlying behavior - the way JVM does for Cloneable or any other standard marker interface for that matter.

Defining an user-defined marker interface in Java

Let's define a user-defined marker interface. Let's say there is an app suporting a medical store inventory and suppose you need a reporting showing the sale, revenue, profit, etc. of three types of medicines - allopathic, homeopathic, and ayurvedic separately. Now all you need is to define three marker interfaces and make your products (medicines) implement the corresponding ones.

public interface Allopathic{}

public interface Homeopathic{}

public interface Ayurvedic{}

In your reporting modules, you can probably get the segregation using something similar to below:-

for (Medicine medicine : allMedicines) {

if (medicine instanceof Allopathic) {

//... update stats accordingly

}

else if (medicine instanceof Homeopathic) {

//... update stats accordingly

}

else if (medicine instanceof Ayurvedic) {

//... update stats accordingly

}

else {

//... handle stats for general items

}

}

As you can see the medicines themselves don't need to implement any specific behavior based on whether they are allopathic, homeopathic, or ayurvedic. All they need is to have a way of reflecting which category they belong to, which will in turn help the reporting modules to prepare the stats accordingly.

Now this can be done by having a flag as well... yeah, sure it can be. But, don't you think tagging a class makes it more readable than having a flag indicating the same. You kind of make it an implementation-independent stuff for the consumers of your classes. If your class implements an interface, it becomes part of the class signature of the published API. Otherwise, you would probably handle the situation by having a public final field having the flag set up at the time of instantiation - final because you would not like others to change it. I guess going the marker interface way would probably make more sense in many such situations.

Another advantage of going via marker interface way is that at any point of time you can easily cast the objects of the implementing classes. Again it's not that if you go via public final approach, you can't do that. You can very well do, but casting might look a cleaner approach in many situations.

The bottom-line is there will hardly be any enforced need for a designer/developer to go via that way as there can be possible alternatives, but marker interfaces can surely be a preferred choice for some in some cases.

Note: Annotations are considered as another possible (quite popular as well) alternative to marker interfaces. Read more about them in this article - Annotations in Java >>

Liked the article? Subscribe to this blog for regular updates. Wanna follow it to tell the world that you enjoy GeekExplains? Please find the 'Followers' widget in the rightmost sidebar.

Purpose of having marker interfaces in Java i.e., why to have marker interfaces?

The main purpose to have marker interfaces is to create special types in those cases where the types themselves have no behavior particular to them. If there is no behavior then why to have an interface? Because the implementor of the class might only need to flag that it belongs to that particular type and everything else is handled/done by some other unit - either internal to Java (as in the case of Java supplied standard marker interfaces) or an app specific external unit.

Let's understand this by two examples - one in which we will discuss the purpose of a standard Java interface (Cloneable) and then another user-created marker interface.

What are Marker Interfaces in Java?

Definition
An empty interface having no methods or fields/constants is called a marker interface or a tag interface. This of course means if the interface is extending other interfaces (directly or indirectly) then the super interfaces must not have any inheritable member (method or field/constant) as otherwise the definition of the marker interface (an entirely empty interface) would not be met. Since members of any interface are by default 'public' so all members will be inheritable and hence we can say for an interface to be a marker interface, all of its direct or indirect super interfaces should also be marker. (Thanks marco for raising the point. I thought it was obvious, but mentioning all this explicitly would probably help our readers.)

There are few Java supplied marker interfaces like Cloneable, Serializable, etc. One can create their own marker interfaces the same way as they create any other interface in Java.