Boost logo

Boost :

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2006-07-04 15:09:52

Dean Michael Berris wrote:
> On 7/4/06, Emil Dotchevski <emildotchevski_at_[hidden]> wrote:
>> I don't think it can be completely avoided. If you throw
>> failed<foo>, you should catch(foo &) to handle the exception. At
>> this point you do need a dynamic_cast to get to the exception_info
>> sub-object. You could have a virtual function in foo to get you an
>> exception_info *, but I don't think that this is appropriate.
> Let's see:
> template <typename _T>
> class failed : public exception_info, public std::exception {
> public:
> failed() { };
> explicit failed (const _T & e) : _wrapped_exception(e) { };
> // ... other common methods ...
> };
> //...
> try {
> ...
> } catch (exception_info & e) {
> ...
> }
> where `e` is already an exception_info reference.

Yes, but that's how it's done in the exception lib when the exception is
caught in otherwise exception-neutral contexts, only for the purpose to add
info to it; no need for dynamic_cast there.

But when you handle the exception, you shouldn't catch exception_info &, you
should catch T (from your example). And now you need dynamic_cast to get to
the exception_info sub-object.

>>> This also seems like too much work for exception handling -- which
>>> seems harder to do than just creating my own exception class which
>>> derives from std::exception, and then a custom constructor that
>>> contains a copy of the information object that I know I want to be
>>> available from those that will be receiving the exception.
>> When you say that you can just create your own exception class, do
>> you mean that you'd create a different exception class for each
>> combination of context information you want to bundle in it?
> Granted that the idea is that the exceptions themselves will be
> designed by me, and that I know what code will require what
> information, it sounds like a reasonable way of going about it --
> compared to doing a dynamic_cast all the time, and the interface being
> not so clear and "developer friendly".

But that's far from granted! Consider this example:

void copy_file( char const * name1, char const * name2 )
    boost::shared_ptr<FILE> f1 = my_fopen(name1,"rb");
    boost::shared_ptr<FILE> f2 = my_fopen(name2,"wb");
        my_fread( buf, 1, buf_size, f1 ); //throws by
        my_fwrite( buf, 1, buf_size, f2 ); //throws by
    catch( exception_info & xi )
        xi << wrap_string<source_name>(name1) <<

OK, you are the designer of the my_fread and my_fwrite functions, and the
file_read_error and file_write_error exceptions they throw. How do you know
that a user will use them in a copy operation? You can't provide for storing
a source and target file name in the exception objects without knowing that,
can you?

This is why the exception lib is necessary, because the context information
is really that: context information. It depends on the context in which the
code that throws is being called, and is out of your control and beyond your
knowledge. The idea is to always use the failed function template when
throwing, even if you don't have info to add to the exception at the point
of the throw. This way you enable higher stack loations to add context
information by catching you as exception_info &.

>>> Is there a good reason why you're not using a "composite-style" [see
>>> GoF composite pattern] exception if you intend to be able to add
>>> information as the exception is propagated through the try {}
>>> catch(...) {} blocks?
>> If you catch(...), you can't do anything to the exception object.
>> That's why you need class exception_info: so you can
>> catch(exception_info&) and add info to it, regardless of T in a
>> throw failed<T>(). Or did you mean to use composite pattern to
>> organize the information in an exception_info? Could you illustrate
>> this with an example?
> I meant for general catch blocks, I didn't intend to say that the
> literal catch(...) {} blocks. Something like this:
> struct composite_exception {
> std::vector<composite_exception> _exceptions;
> void add(const composite_exception & e) {
> _exceptions.add(composite_exception(e));
> }
> explicit composite_exception(const composite_exception & other) :
> _exceptions(other._exceptions) { };
> composite_exception() {};
> // add common methods here, like "what()"
> };
> So you can do something like:
> try {
> } catch (composite_exception & e) {
> //... iterate through the vector
> };

But by catching composite_exception &, you are really using value semantics
to handle the exception. It's like sayng that you can always throw integer
error codes, then catch( int ), and do a switch-case on the error code.

In C++, we use types (not values) to differentiate between the different
types of errors. The exception lib does not violate this principle: the
value semantics of class exception_info are not intended for figuring out
how to respond to the exception. When you throw failed<foo>(), you would
catch(foo &) (or any of its public base types) to handle the exception; the
exception_info sub-object is there only to provide context information, such
as file names or whatever else makes sense for the user to see.


Boost list run by bdawes at, gregod at, cpdaniel at, john at