8.8 NO_DATA_FOUND: Multipurpose Exception

Chapter 8
Exception Handlers

 

---

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.