Re: [boost] Review Request: Boost Exception

From: Tom Brinkman (reportbase_at_[hidden])
Date: 2007-07-15 17:37:02

>> I am contemplating refactoring boost::filesystem to use the proposed
>> boost::exception for demonstration purposes. Would anyone be interested in
>> seeing such an example?

That could be interesting.  It might start a good discussion about
"exceptions" in general.

On 7/9/07, Emil Dotchevski <emildotchevski_at_[hidden]> 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/
>
> 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_at_[hidden]> 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.
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>