What exactly do you expect in this context?
Well, like I said, it is typical for a C/C++ preprocessor to allow macro re-definitions in violation of the standard, and there's likely quite a bit of [sloppy] code that won't be processed correctly otherwise. I am not 100% sure what is the best paradigm for handling this situation in the context of Wave. It would, of course, be nice to have a generic mechanism for rolling back to pre-error state of the lexer/preprocessor system while providing sufficient information to enact recovery (i.e. providing the name of a failed macro so that user's code can call undefine_macro() and re-process the failed definition). I imagine that may be quite expensive, however, as it might entail having to save the state in the beginning of any operation that may consume tokens from the input without returning them to user -- potentially any operation! Perhaps a cheaper way is adding another hook to the context policy? For example, template<typename X> bool pre_exception( const X& err ); that will have a chance to recover and return true or return false and allow the exception to proceed. Again, I am not sure just how easy it would be to incorporate such a policy hook into the existing code. In simple cases, the sequence of: action; if( test ) throw some_exception( parameters ); could be rewritten as do { action; } while( !test && checked_throw( some_exception( parameters ) ) ); where template <typename X> bool checked_throw( const X& x ) { if( !pre_exception(x) ) throw x; return false; } but it requires "action" to leave the system state unchanged whenever "test" is true at the end of it. This may be easy to achieve in some cases and hard in others; aside from that, enough information has to be delivered to pre_exception() to undertake sensible actions which in all likelihood will require creating a separate exception class for each type of error or at least many of them. After all, the easiest course may be to provide a default error recovery option for most errors. Which may not be all that bad: for macro re-definition, use the new definition; for #undefine unknown macro -- ignore etc. I guess your is_recoverable() mechanics is good enough for that already, as long as the default recovery actions are reasonable. Wave is a fairly specialized library and natural expectation is that it would be used by either C/C++ compilers or other applications working with C or C++ code in a way similar to a compiler (in my case -- a code instrumentation tool that attempts partial parsing of class definitions). Thus any such code should benefit from handling preprocessor errors in the same exact way a typical C++ compiler would handle them. I figured you were asking for my 2c, so now you got them in spades ;-) ...Max...