Wait, that's NOT a reserved word?

When it comes to PL/SQL puzzles via Twitter, I decided to change things up this week. I presented it as multiple choice this time.

Here's the puzzle:

After executing the code shown in the image what will be displayed on the screen (serveroutput is on!)?

a. "No dummy"
b. Unhandled VALUE_ERROR exception
c. Unhandled NO_DATA_FOUND exception
d. Compilation error
e. Your guess is as good as mine.

Before I unveil the amazing, mind-boggling answer....I will give you a moment to try to solve it yourself.

OK. So the first inclination you might have as regards the output from this block is, quite logically, "No dummy!".

After all, there are no rows in the dual table (or any other table for that matter) for which 1 is equal to 2.

So that SELECT-INTO is going to raise a NO_DATA_FOUND exception. No doubt about that at all.

And there's an exception handler for NO_DATA_FOUND (well, no_data_found, wait they are the same thing in PL/SQL! :-) ). So "No dummy" it is, right?

Wrong.

Now, a number of people in Twitterland also chose (d) Compilation error.

They reasoned that "no_data_found" and "pls_integer" are reserved words in PL/SQL. So if you try to use them for your own identifiers, the PL/SQL compiler slaps you down.

That's very solid reasoning....and it would be true if those were actually reserved words.

Now, IF is definitely a reserved word, so if I try to declare a variable with that name, nuh-uh:

NO_DATA_FOUND and PLS_INTEGER are not reserved words, which you can confirm with a query in your database:

That's right - I got a NO_DATA_FOUND exception searching for "NO_DATA_FOUND" as a reserved word. :-)

OK but to be completely honest with you, that view contains SQL keywords. Check Appendix D of the PL/SQL Language Reference for PL/SQL Reserved Words and Keywords.

So "no_data_found" and "pls_integer" are not reserved words, which means I can use them myself in my code. Which then means that any usage of those names in my block will be resolved to my variables or types or whatever they are, and not the pre-defined element in the PL/SQL language.

Specifically the "when no_data_found" handler will trap only the no_data_found exception that I declared in my code, which is not the same exception as that raised by the PL/SQL runtime engine.

In fact, the only way that handler could trap anything is if "RAISE no_data_found" was executed in this block.

I hope that makes sense. It is of course very confusing and even if "no_data_found" is not a reserved word, you should certainly avoid using it for your own identifiers in your code.

But if "no_data_found" is not a reserved word, what is it? Is it a keyword? Not even that. It doesn't appear in the D-2 table, but you should think of it as a keyword since the word on keywords is "You can use keywords as ordinary user-defined identifiers, but it is not recommended."

In fact, "no_data_found" is an exception declared in a special package called STANDARD. That package is owned by SYS and, along with DBMS_STANDARD, define many elements of the PL/SQL language, including exceptions like DUP_VAL_ON_INDEX and VALUE_ERROR and types like PLS_INTEGER.

You can view the package source as follows:

  SELECT line, text
    FROM all_source
   WHERE TYPE = 'PACKAGE' AND name = 'STANDARD' AND owner = 'SYS'
ORDER BY line

You can also view the package body, but it's not very helpful, except to reveal to you that the PL/SQL dev team has access to functionality that we do not. Which should not come as a surprise to anybody.

In that package specification, you will find lines of code like this:

At which point, I am sure you are now saying to yourself: "What? What is that number for NO_DATA_FOUND? 100? I thought the error code for this exception was -1403." Yeah, it's a rather strange outlier of an exception. Bottom line is that the ANSI standard error code for "no data found" is 100, so we go with that, but when the exception is raised, SQLCODE returns -1403.

Get over it.

And there you have it. Now you know that you, too, can write code that is so hard to read, so confusing, so downright strange that everyone will conclude that you must be a genius.

Since, however, neither you nor I are a genius, I suggest you never write code like this.