Oracle PL/SQL Programming, 2nd Edition

• Oracle PL/SQL Programming, 2nd Edition
• Search this book

8.8 NO_DATA_FOUND: Multipurpose Exception

The NO_DATA_FOUND exception is raised under three different circumstances:

• An implicit query returns no data.

• You attempt to reference a row in a PL/SQL table which has not been defined. (PL/SQL tables are covered in Chapter 10, PL/SQL Tables .)

• You attempt to read past the end of an operating system file (using TEXT_IO in the Oracle Developer 2000 environment or UTL_FILE in PL/SQL Release 2.3).

This overlapping use of the same exception could cause some confusion and difficulty in your program. Suppose that in a single PL/SQL block I query from an implicit cursor and also make references to a PL/SQL table's rows. The NO_DATA_FOUND exception could be raised from either source, but the actual problem that caused the exception would be very different: bad data in the database (raised by the implicit cursor) versus an illegal memory reference (raised by the table access).

I want to be able to distinguish between the two situations. I can accomplish this by nesting the SELECT statement (the implicit cursor) inside its own PL/SQL block and thus trapping the NO_DATA_FOUND exception distinct from the PL/SQL table exception.

In the version of company_name shown in the following example, I have added a parameter to specify two types of access: from database (access type = DBMS) or from a PL/SQL table (access type = MEMORY). I want to check for NO_DATA_FOUND for each particular instance:

FUNCTION company_name
 (id_in IN NUMBER, access_type_in IN VARCHAR2)
RETURN VARCHAR2
IS
 /* Return value of the function */
 return_value VARCHAR2 (60);
 /* My own exception - used to represent bad data NO_DATA_FOUND. */
 bad_data_in_select EXCEPTION;
BEGIN
 /* Retrieve company name from the database */
 IF access_type_in = 'DBMS'
 THEN
 /* Place the SELECT inside its own BEGIN-END. */
 BEGIN
 SELECT name INTO return_value
 FROM company
 WHERE company_id = id_in;
 RETURN return_value;
 /* Now it can have its OWN exception section too ! */
 EXCEPTION
 /* This NO_DATA_FOUND is only from the SELECT. */
 WHEN NO_DATA_FOUND
 THEN
 /*
 || Raise my exception to propagate to
 || the main body of the function.
 */
 RAISE bad_data_in_select;
 END;
 /* Retrieve company name from an in-memory PL/SQL table */
 ELSIF access_type_in = 'MEMORY'
 THEN
 /*
 || Direct access from table. If this ID is not defined
 || then the NO_DATA_FOUND exception is raised.
 */
 RETURN company_name_table (id_in);
 END IF;
EXCEPTION
 /*
 || This exception occurs only when NO_DATA_FOUND was raised by
 || the implicit cursor inside its own BEGIN-END.
 */
 WHEN bad_data_in_select
 THEN
 DBMS_OUTPUT.PUT_LINE
 (' Unable to locate company in database!');
 /*
 || This exception occurs only when I have not previously placed
 || the company name for company id id_in in the table.
 */
 WHEN NO_DATA_FOUND
 THEN
 DBMS_OUTPUT.PUT_LINE
 (' Unable to locate company in memorized table!');
END;

You can see how the scoping rules for exceptions provide a great deal of flexibility in managing the impact of exceptions. Whenever you want to isolate the effect of a raised exception, just nest the statements inside their own BEGIN-END, give them their own exception section, and then decide what you want to do when the problem occurs. You are guaranteed to trap it there first.