"Geoff Leyland" <gley001@ec.auckland.ac.nz> wrote in message:
I think, though, that not all exceptions are created equal. When I first started using exceptions I wrote an exception class that had static buffers for the data it might need to store, because I
that exceptions might be thrown in low memory situations. I don't think I have ever seen any of my code throw an out of memory exception. I don't think I've ever seen a string constructor throw. I know
the stream operators could probably throw, but they don't very much compared to the mistakes I make.
I have also been down the road of writing loads of little exception classes for different kinds of problem, each containing the relevant fields for the particular type of exception, so that all the data you needed to interpret the exception was available in the public interface of the exception. Needless to say, it was a pain in the ass, and I never wrote any code that interpreted the data in the exception (except to format "what")
In my little command line world, the errors I usually get are that people have forgotten a key-value pair in an input file, or they've spelt the path to a plugin wrong.
I could print out the problem and try to continue, and inevitably crash.
I could print out the problem and exit or assert, but sometimes I'm running hundreds of tests over a few days, and I don't want the damn thing to stop completely in the middle of the night because I've made a mistake configuring one of the tests.
So what I do is throw an exception with a readable message. The
thought that main
program running the test loop can catch these exceptions, store them all up, and print them all out right at the end of the tests, telling me which tests had problems and why, so that they don't get lost in all the other guff the tests are printing out.
There are lots of legitimate reasons for throwing lots of types of exceptions, and I'm not implying that throwing some kind of "streamy_exception" is appropriate in all (or even more than a few) places, but it has made my life a lot easier, and made a lot of silly mistakes easier to fix.
Are you proposing a single new exception which overloads operator<<, for use in testing, or are you thinking of using it as a framework for user-define exceptions in situations where the programmer judges that low resources will not be a problem? 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. Also, have you looked at Boost.Test? Jonathan