I guess pointing at the documentation of the proposed Boost Exception counts as generating buzz :) http://www.revergestudios.com/boost-exception/boost-exception.htm The source code with boost-build jamfiles and tests can be downloaded here: http://www.revergestudios.com/boost-exception/boost-exception.zip The source code is also available for online browsing: http://www.revergestudios.com/boost-exception/ As for selling the library, I can point out the 3 main advantages of using Boost Exception: 1) With Boost Exception, exception class design is decoupled from what data each exception object needs to transport to the catch site. For example, consider boost::filesystem, the basic_filesystem_error class template is designed to store 2 paths, called path1 and path2. If Boost Exception was used, there would be no need to anticipate all possible data that could be available to the throw site (note that some such data could be platform-specific), and also it would be possible to give more meaningful names to path1 and path2. 2) Contexts above the throw site can add data to any boost::exception that passes by. If we consider a boost::filesystem example again, a library that uses boost::filesystem but does not handle the exceptions boost::filesystem emits could intercept a "file not found" exception and augment it with library-specific information about the failure. 3) Without Boost Exception, often it is necessary to pass data to a throw site just so it can pack it in exceptions in case of failure. Typical example is a file read operation: somehow, you need to make the file name available to it, even though the read operation itself doesn't need it. With Boost Exception, the context that detects and reports a file read error wouldn't put the file name in the exception in throws -- this will be done by the context that opened the file, by intercepting _any_ boost::exception and augmenting it with the file name (because the file name is relevant to any failures, not only I/O failures). I am contemplating refactoring boost::filesystem to use the proposed boost::exception for demonstration purposes. Would anyone be interested in seeing such an example? Emil Dotchevski Felipe Magno de Almeida wrote:

On 7/8/07, Tom Brinkman <reportbase@gmail.com> wrote:

...

No one has stepped up to volunteer to be the review manager. I suggest that you generate a little buzz around the library, post a couple of threads and "sell" your library to the boost developers. C++ "exceptions" are a controversial topic with many different points of view. Tell us why we need boost::exception and why does your library solve that need?

It is not mine library, but I really see potential in this library. Every time I need something like this I remember this proposal and find that it hasn't been reviewed yet.

Emil Dotchevski wrote:

I guess pointing at the documentation of the proposed Boost Exception counts as generating buzz :)

http://www.revergestudios.com/boost-exception/boost-exception.htm

The source code with boost-build jamfiles and tests can be downloaded here:

http://www.revergestudios.com/boost-exception/boost-exception.zip

The source code is also available for online browsing:

http://www.revergestudios.com/boost-exception/ [TRUNCATE]

Based on a quick read of the documentation: 1. What happens if a "boost::error_info" tag is used multiple times on the same object? Is it an error (exception or assert?), do the instances get combined like a multi-set, or do all instances besides the first (or last) get ignored/dropped? Shouldn't this be documented? 2. Shouldn't all inheritance of "boost::exception," especially via "enable_error_info," be of the virtual kind? Catching a given class type only works if it has exactly one connection to the actual exception object, which means that: a. The type is the final type of the object b. The type appears exactly once in the inheritance hierarchy c. All inheritance appearances of the type are virtual If a class type uses another type as a base multiple times, and at least one appearance is _not_ virtual, then catches with that base will be skipped when that first type is thrown. Imagine what happens if "enable_error_info" is applied multiple times during an exception session and/or the original exception object used "boost::exception". -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com