|
Boost : |
From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-02-09 21:13:54
"Reece Dunn" <msclrhd_at_[hidden]> wrote in message
news:BAY7-F110BnccYTjr8c0004e373_at_hotmail.com...
> Jonathan Turkanis wrote:
> >To me, the ability to write an exception to a stream is
unimportant,
> >since you can just use what(). The ability to write to an exception
> >class using operator<< has a certain appeal; I would defintely use
if
> >it were free. On the other hand, if the stream operations are only
> >happening before the exception is thrown, and if you are dealing
with
> >an exception type that already has the ability to hold some text,
you
> >can get the same effect by using a stringstream. I'm not sure it's
> >worth introducing a new exception class just to save programmers
the
> >trouble of defining a stringstream. Maybe for use in certaint types
of
> >testing it would be helpful.
>
> Using a stringstream would be my approach to achieve this affect,
but I
> wonder what would happen if the stream operation generated an
exception?
> E.g.
>
> throw( std::ostringstream() << "Error #" << 404 << weberror(
404 ));
>
> what if weberror thows an exception? Also, is ostringstream
guaranteed not
> to throw an exception?
>
> Throwing an exception during the exception process is not a good
idea!
I agree. It's not as bad as letting an exception escapre from a
destructor, but it's still best avoided, since the original error
never gets reported. That's why I mentioned the exception guidlines in
my first post.
I was trying say :-) that if you decide you don't care about these
problems, in a particular usage scenario, you can essentially get
effect of overloading operator<< by just using a stringstream.
Best Regards,
Jonathan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk