Peter Siebel - Practical Common Lisp

(format nil "I saw ~r el~:*~[ves~;f~:;ves~]." 0) ==> "I saw zero elves."

(format nil "I saw ~r el~:*~[ves~;f~:;ves~]." 1) ==> "I saw one elf."

(format nil "I saw ~r el~:*~[ves~;f~:;ves~]." 2) ==> "I saw two elves."

In this control string, the ~Rprints the format argument as a cardinal number. Then the ~:*directive backs up so the number is also used as the argument to the ~[directive, selecting between the clauses for when the number is zero, one, or anything else. [199] f you find "I saw zero elves" to be a bit clunky, you could use a slightly more elaborate format string that makes another use of ~:* like this: (format nil "I saw ~[no~:;~:*~r~] el~:*~[ves~;f~:;ves~]." 0) ==> "I saw no elves." (format nil "I saw ~[no~:;~:*~r~] el~:*~[ves~;f~:;ves~]." 1) ==> "I saw one elf." (format nil "I saw ~[no~:;~:*~r~] el~:*~[ves~;f~:;ves~]." 2) ==> "I saw two elves."

Within an ~{directive, ~*skips or backs up over the items in the list. For instance, you could print only the keys of a plist like this:

(format nil "~{~s~*~^ ~}" '(:a 10 :b 20)) ==> ":A :B"

The ~*directive can also be given a prefix parameter. With no modifiers or with the colon modifier, this parameter specifies the number of arguments to move forward or backward and defaults to one. With an at-sign modifier, the prefix parameter specifies an absolute, zero-based index of the argument to jump to, defaulting to zero. The at-sign variant of ~*can be useful if you want to use different control strings to generate different messages for the same arguments and if different messages need to use the arguments in different orders. [200] This kind of problem can arise when trying to localize an application and translate human-readable messages into different languages. FORMAT can help with some of these problems but is by no means a full-blown localization system.

And there's more—I haven't mentioned the ~?directive, which can take snippets of control strings from the format arguments or the ~/directive, which allows you to call an arbitrary function to handle the next format argument. And then there are all the directives for generating tabular and pretty-printed output. But the directives discussed in this chapter should be plenty for the time being.

In the next chapter, you'll move onto Common Lisp's condition system, the Common Lisp analog to other languages' exception and error handling systems.

One of Lisp's great features is its condition system. It serves a similar purpose to the exception handling systems in Java, Python, and C++ but is more flexible. In fact, its flexibility extends beyond error handling—conditions are more general than exceptions in that a condition can represent any occurrence during a program's execution that may be of interest to code at different levels on the call stack. For example, in the section "Other Uses for Conditions," you'll see that conditions can be used to emit warnings without disrupting execution of the code that emits the warning while allowing code higher on the call stack to control whether the warning message is printed. For the time being, however, I'll focus on error handling.

The condition system is more flexible than exception systems because instead of providing a two-part division between the code that signals an error [201] Throws or raises an exception in Java/Python terms and the code that handles it, [202] Catches the exception in Java/Python terms the condition system splits the responsibilities into three parts— signaling a condition, handling it, and restarting . In this chapter, I'll describe how you could use conditions in part of a hypothetical application for analyzing log files. You'll see how you could use the condition system to allow a low-level function to detect a problem while parsing a log file and signal an error, to allow mid-level code to provide several possible ways of recovering from such an error, and to allow code at the highest level of the application to define a policy for choosing which recovery strategy to use.

To start, I'll introduce some terminology: errors , as I'll use the term, are the consequences of Murphy's law. If something can go wrong, it will: a file that your program needs to read will be missing, a disk that you need to write to will be full, the server you're talking to will crash, or the network will go down. If any of these things happen, it may stop a piece of code from doing what you want. But there's no bug; there's no place in the code that you can fix to make the nonexistent file exist or the disk not be full. However, if the rest of the program is depending on the actions that were going to be taken, then you'd better deal with the error somehow or you will have introduced a bug. So, errors aren't caused by bugs, but neglecting to handle an error is almost certainly a bug.

So, what does it mean to handle an error? In a well-written program, each function is a black box hiding its inner workings. Programs are then built out of layers of functions: high-level functions are built on top of the lower-level functions, and so on. This hierarchy of functionality manifests itself at runtime in the form of the call stack: if highcalls medium, which calls low, when the flow of control is in low, it's also still in mediumand high, that is, they're still on the call stack.

Because each function is a black box, function boundaries are an excellent place to deal with errors. Each function— low, for example—has a job to do. Its direct caller— mediumin this case—is counting on it to do its job. However, an error that prevents it from doing its job puts all its callers at risk: mediumcalled lowbecause it needs the work done that lowdoes; if that work doesn't get done, mediumis in trouble. But this means that medium's caller, high, is also in trouble—and so on up the call stack to the very top of the program. On the other hand, because each function is a black box, if any of the functions in the call stack can somehow do their job despite underlying errors, then none of the functions above it needs to know there was a problem—all those functions care about is that the function they called somehow did the work expected of it.

In most languages, errors are handled by returning from a failing function and giving the caller the choice of either recovering or failing itself. Some languages use the normal function return mechanism, while languages with exceptions return control by throwing or raising an exception. Exceptions are a vast improvement over using normal function returns, but both schemes suffer from a common flaw: while searching for a function that can recover, the stack unwinds, which means code that might recover has to do so without the context of what the lower-level code was trying to do when the error actually occurred.

Consider the hypothetical call chain of high, medium, low. If lowfails and mediumcan't recover, the ball is in high's court. For highto handle the error, it must either do its job without any help from mediumor somehow change things so calling mediumwill work and call it again. The first option is theoretically clean but implies a lot of extra code—a whole extra implementation of whatever it was mediumwas supposed to do. And the further the stack unwinds, the more work that needs to be redone. The second option—patching things up and retrying—is tricky; for highto be able to change the state of the world so a second call into mediumwon't end up causing an error in low, it'd need an unseemly knowledge of the inner workings of both mediumand low, contrary to the notion that each function is a black box.