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
"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:BAY7-F110BnccYTjr8c0004e373@hotmail.com... 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