Skip to main content

Don't Want to Remember No Stinking Error Codes

Programmers need to keep lots of information in their heads: about the language(s) with which they are writing code, the data model of their application, requirements, etc. So they tend to not remember (and even forget rather quickly) information they are pretty sure is not in their critical path.

I was reminded of this very forcefully at a two day course I gave in the Netherlands a few years ago. On the first day, I talked about FORALL and SAVE EXCEPTIONS, and how Oracle would raise ORA-24381 if at least one statement failed in the FORALL's execution.

Then at the end of the second day, when I discussed maintainability, I again talked about ORA-24381 (for reasons that will become clear below). And then, then it was time for the end-of-course ten-part quiz, with reputation and prizes on the line.

Lo and behold, when the dust settled, we had a tie for first place. So then it was time for a sudden death playoff. Whoever gave me the right answer first, wins.

I showed "-24381" on the screen and asked: "With what feature of PL/SQL is this number associated?"

Neither of the expert finalists had an answer and, amazingly, no one else in the class of 40 did, either.

It was very clear to me at that point that these developers....

Don't Want to Remember No Stinking Error Codes

OK, fine. It's a lot better to remember and work with meaningful names, than obscure numbers, right? As in:

DECLARE
   l_numbers DBMS_SQL.NUMBER_TABLE;
BEGIN
   DBMS_OUTPUT.PUT_LINE (l_numbers (1));
EXCEPTION
   WHEN NO_DATA_FOUND
   THEN
      DBMS_OUTPUT.PUT_LINE (
         'Tried to read an undefined index value!');
END;

And that's why Oracle gives names in the default STANDARD package to a whole bunch of the most commonly-occurring exceptions, such as NO_DATA_FOUND and VALUE_ERROR.

Sadly, no name was supplied for ORA-24381, so I guess that means we need to write code like this:

EXCEPTION
   WHEN OTHERS
   THEN
      IF SQLCODE = -24381
      THEN
         /* Traverse SQL%BULK_EXCEPTIONS for DML errors */
         ...
      ELSE
         RAISE;
      END IF;
END;

Really? Is that really what we have to do? I sure hope not, because this is (confession: slight exaggeration coming) horrifying, nervous breakdown-inducing code.

OK, maybe it's not that bad. But think about it: you write code today and it goes into production tomorrow. You move on to another project, and the code lives on. Five years later, a bug surfaces in that program, and someone who has never looked at your code opens it up and sees:

IF SQLCODE = -24381

and you know how it makes them feel? Ignorant, stupid, diminished. Afraid to touch your code, because you are/were obviously much smarter (or at least more expert with PL/SQL) than they. You obviously knew all about those weird error codes and they have no clue.

Now, if one of your objectives in writing code is trying to make other people feel bad and thereby pump yourself up, it's not that hard to do. Just write code that is hard to understand, maintain and debug. Leave out comments, hard-code magic values left and right. Then express astonishment when someone has trouble understanding what you wrote.

There are many words for programmers like this. One of them likely starts with an "a".

But if that's not the kind of programmer you want to be, if you'd rather be the sort who goes out of their way to make people feel welcome in their code, in which the intention and the algorithm are evident, and these "next generation" developers can make changes with some degree of confidence, then do like Oracle does:

Reference those obscure error codes by name.

But, wait, you are thinking: "Steven just said that Oracle did not define a name for ORA-24381."

Yes, that is so. But nothing is stopping you from doing that yourself!

Create a package to hold all of your named exceptions, and then do the same thing that you will find in STANDARD: use the EXCEPTION_INIT pragma to associate a named exception with a number:

CREATE OR REPLACE PACKAGE my_errors
IS
   forall_failure EXCEPTION;
   PRAGMA EXCEPTION_INIT (forall_failure, -24381);
END;
/

You can then reference those obscure error codes by name.

EXCEPTION
   WHEN my_errors.forall_failure
   THEN
      /* Traverse SQL%BULK_EXCEPTIONS for DML errors */
     ...
END;

No more hard-coding of error codes, no more expecting others to have the same relatively random, highly specialized knowledge you acquired.

In short, no showing off.


Comments

  1. Hello Steven,

    Maybe not exactly pertaining to this discussion only ...
    I just had a look at some SQL solutions posted up to now for the currently ongoing "Obfuscated SQL Contest" .

    You say:
    "Now, if one of your objectives in writing code is trying to make other people feel bad and thereby pump yourself up, it's not that hard to do.
    Just write code that is hard to understand, maintain and debug."

    To tell you the truth ?
    This is exactly how I felt when looking at some of those solutions ... and, for sure,
    "the winner" will be one of those ...

    I hope that you know what is the meaning of "K.I.S.S." ...
    when talking about software, of course ...

    Thanks a lot & Best Regards,
    Iudith

    ReplyDelete
  2. Never RAISE_APPLICATION_ERROR again... http://www.oraclenerd.com/2010/10/never-use-raiseapplicationerror-again.html

    ReplyDelete

Post a Comment

Popular posts from this blog

Quick Guide to User-Defined Types in Oracle PL/SQL

A Twitter follower recently asked for more information on user-defined types in the PL/SQL language, and I figured the best way to answer is to offer up this blog post. PL/SQL is a strongly-typed language . Before you can work with a variable or constant, it must be declared with a type (yes, PL/SQL also supports lots of implicit conversions from one type to another, but still, everything must be declared with a type). PL/SQL offers a wide array of pre-defined data types , both in the language natively (such as VARCHAR2, PLS_INTEGER, BOOLEAN, etc.) and in a variety of supplied packages (e.g., the NUMBER_TABLE collection type in the DBMS_SQL package). Data types in PL/SQL can be scalars, such as strings and numbers, or composite (consisting of one or more scalars), such as record types, collection types and object types. You can't really declare your own "user-defined" scalars, though you can define subtypes  from those scalars, which can be very helpful from the p

The differences between deterministic and result cache features

 EVERY once in a while, a developer gets in touch with a question like this: I am confused about the exact difference between deterministic and result_cache. Do they have different application use cases? I have used deterministic feature in many functions which retrieve data from some lookup tables. Is it essential to replace these 'deterministic' key words with 'result_cache'?  So I thought I'd write a post about the differences between these two features. But first, let's make sure we all understand what it means for a function to be  deterministic. From Wikipedia : In computer science, a deterministic algorithm is an algorithm which, given a particular input, will always produce the same output, with the underlying machine always passing through the same sequence of states.  Another way of putting this is that a deterministic subprogram (procedure or function) has no side-effects. If you pass a certain set of arguments for the parameters, you will always get

My two favorite APEX 5 features: Regional Display Selector and Cards

We (the over-sized development team for the PL/SQL Challenge - myself and my son, Eli) have been busy creating a new website on top of the PLCH platform (tables and packages): The Oracle Dev Gym! In a few short months (and just a part time involvement by yours truly), we have leveraged Oracle Application Express 5 to create what I think is an elegant, easy-to-use site that our users will absolutely love.  We plan to initially make the Dev Gym available only for current users of PL/SQL Challenge, so we can get feedback from our loyal user base. We will make the necessary adjustments and then offer it for general availability later this year. Anyway, more on that as the date approaches (the date being June 27, the APEX Open Mic Night at Kscope16 , where I will present it to a packed room of APEX experts). What I want to talk about today are two features of APEX that are making me so happy these days: Regional Display Selector and Cards. Regional Display Sel