Edith Wharton has been quoted as saying that “There are two ways of spreading light: to be the candle or the mirror that reflects it.” Windows error messages often seem to put out the light rather than spread it. Ezzell’s new book on error messages seeks to spread light. Directed at software developers, and especially at down-and-dirty coders, it argues for more detailed messages, which mortal users can figure out. Ezzell also presents some tools to help C, C++, and Visual Basic programmers put his ideology into practice.
Chapter 1, which analyzes “the errors in error messages,” covers no new ground. It is, however, a good, brief summary of why current error messages are so cryptic, except to the person who wrote the code. Chapter 2, on error prevention, is more insightful and contains new thoughts, such as the idea that it is entirely possible to hide some errors from users. Can there be some errors so routine that code can be written to handle them automatically? Ezzell argues that it can be done, and if you think about it, you may be inclined to agree. Chapter 3 presents Ezzell’s suggestions for an information-rich, standardized error message format, supported by his arguments in chapter 4 for automated error event logging and online documentation. While Ezzell presents the case for Internet error support, many users are not online all the time, and Internet support may not be practical in many cases. Even where it is accessible, the inconvenience may cause so much user dissatisfaction that market considerations should be paramount. Consider, for example, IBM Visual Age products, which rely heavily on Internet support for documentation of advanced features.
What is unusual about this book is the included CD-ROM, which includes complete DLLs for Visual Basic, C, C++, and Microsoft Foundation Classes (MFC). The DLL libraries included have support for all the error displays discussed in the text, and they can be included in applications. The author provides a dose of realism, such as in the discussion of the “strong temptation for programmers accustomed to using the MFC classes to use a CString member in the RegQueryValueEx call. Unfortunately, none of the Registry API functions are MFC compatible and using a CString argument will…also trash the stack.…”
It is a refreshing change to not only be given the theory behind errors and user interfaces, but have it put into practice, and have the practice put into our hands. This is a great book for developers who get their hands dirty; it really casts some light!
