Chapter 19: Diagnostics

Chapter 19 deals with program diagnostics, such as exceptions and assertions. You know, all the things we wish weren't even necessary at all.

Contents

Adding data to exceptions

The standard exception classes carry with them a single string as data (usually describing what went wrong or where the 'throw' took place). It's good to remember that you can add your own data to these exceptions when extending the heirarchy: 

   using std::runtime_error;
   struct My_Exception : public runtime_error
   {
     public:
       My_Exception (const string& whatarg)
           : runtime_error(whatarg), e(errno), id(GetDataBaseID()) { }
       int  errno_at_time_of_throw() const { return e; }
       DBID id_of_thing_that_threw() const { return id; }
     protected:
       int    e;
       DBID   id;     // some user-defined type
   };

Return to top of page or to the FAQ.

Exception class hierarchy diagram

The diagram is in PDF, or at least it will be once it gets finished.

Return to top of page or to the FAQ.

Concept checkers

First the good news, then the bad news.

Good news: As part of their 3.3 release, SGI added some nifty macros which perform assertions on type properties. For example, the Standard requires that types passed as template parameters to vector be "Assignable" (which means what you think it means).

The concept checkers allow the source code for vector to declare 

   __STL_CLASS_REQUIRES(_Tp, _Assignable);
inside the template. _Tp is the element type of the vector, and _Assignable is the concept to be checked (it is defined in some back-end header files). When you instantiate vector<MyType>, compile-time checking can be done on whether MyType meets the requirements for vectors.

Most (all?) of the containers and sequences are capable of performing concept checking during compilation, not just vector.

If a concept is violated (thus causing a compilation failure), the error messages printed by the compiler will be of the form 

   _STL_ERROR::__foo_violation
where foo is a description of the precise violation. For example, if a type is required to support the preincrement operator but doesn't, then you will see _STL_ERROR::__postincrement_operator_requirement_violation, which should give you a hint as to the nature of the problem.

Other names might be seen for more specific errors, for example, _ERROR_IN_STL_CONTAINER::__begin_iterator_accessor_requirement_violation.

You will probably also see other errors as the malformed code is actually used. The concept checking error messages should be printed before the others, so start at the top and work your way down.

Bad news: The current checking code is somewhat messy. It results in no runtime overhead, but there is a space penalty (sometimes a very large one) in the generated code. And the code itself has bugs.

Concept checking can be disabled when you build your code. Just define (via -D or #define) the macro _STL_NO_CONCEPT_CHECKS (yes, with the leading underscore). In fact, this may already be defined in the library by default, depending on what decision we come to.

More good news: Replacement code has already been written by the same author of the original code. It's available at Boost and we hope to integrate it into the library.

Return to top of page or to the FAQ.

Comments and suggestions are welcome, and may be sent to Phil Edwards or Gabriel Dos Reis.
$Id: howto.html,v 1.1 2000/12/10 04:04:54 pme Exp $