3.7. Now What?

The working title of this chapter was "Treasure In, Treasure Out," a phrase that sums up how most of us start out wanting our programs to behave. I've tried to spice up this chapter with various lessons on programming defensively—that is, programming in such a way that you assume the worst conditions will happen. Your programs should be able to deal with garbage in without producing garbage out.

There are a variety of ways to prevent "garbage out syndrome." We've looked at a few of them in the course of creating a package that services and protects the book data in the database. To summarize:

  • Always remember the possibility that PL/SQL variables and parameters can be null, especially when programming IF-THEN logic.

  • Build and use "table wrappers" with PL/SQL; develop the programming discipline needed to use the approach consistently.

  • When declaring parameters for stored routines, give them default values wherever it makes sense to do so.

  • In general, prefer named notation to positional notation, especially when it adds information that needs to be present.

  • Avoid duplication in your code; doing so will make future modifications less prone to errors.

  • Organize your code into packages rather than into a lot of standalone procedures and functions.

  • Handle exceptions where doing so makes sense, but raise exceptions if your program might encounter problems it shouldn't be deciding how to solve.

  • Use overloading to transfer complexity away from the developer and into the ...

Get Learning Oracle PL/SQL now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.