It has been claimed that Common Lisp would provide better error handling than other languages, where "better" equates equally to "provide
superior error handling facilities and to "clear error messages". As a mere application programmer, I strongly believe in that this should carry over to libraries, but unfortunately lately I get the impression that this tradition isn't given enough respect by some of the more younger kids on the block.
As my pet peeve example of late, consider
UCW: it's a prime example of how to assemble a lot of functionality by relying on other libraries. Unfortunately, standing on giants shoulders can be become quite a task if the giants start shaking. To me, UCW gives really horrible error messages. Most of the time, you'll get no idea where to look for the error.
As a simple example, when UCW encounters an error while parsing some tal file, you just might get the error message "NIL is not a character", which won't give you any clue what caused the problem. Sometimes, you won't get an error message at all, but simply get no result at all. As an example, I took one tal file from some test project, modified it a little and tested it on my new application. I didn't get any output from the variables referenced. After a lot of time spend debugging the lisp-side of the code, I finally saw the light: I forgot to change the lisp package referred to in the tal-file header, hence UCW tried (unsuccessfully) to access variables that didn't even exist. A warning (in UCWs log) would have been very helpful.
Another problem might be related to the code walking UCW does: sometimes you may get an error about unbound variables while trying to render some component. With UCW this problem occurs more often (and I think this might be due to the code walking), as sometimes a
(with-slots (foo) component &body) is not sufficient to avoid the accessor, i.e.
(foo component). Well, that kind of error isn't uncommon: it's easy to mistype a variable name or to forget (or -- as in UCWs case -- to not knowing that you should) use the syntax for a variable when instead you should have used a CLOS accessor. So usually, you'll take a quick glance at the error message or the backtrace and then fix the error in the erroneous piece of code. Not so with UCW: usually it's near to impossible to find the damned piece of code because the backtrace won't show you even the name of the component. The name of the variable typically will not be of much help either, if you happen to move state information through several components, (re-)using the same slot names all over the place.
So, to sum up, what I believe is that UCW falls short on is coping with the errors its building blocks may generate. The result is that while the resulting code for some application may be terse and even pretty [1], it may take a lot of time to get it right because of the amount of time wasted debugging unclear error messages. Please, library designers: support your local errors.
Footnotes:
[1] I don't think that the code for an UCW application is pretty, but that's another story.
