[boost] Re: Re: Exceptions as streams

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-02-09 20:36:19

"Geoff Leyland" <gley001_at_[hidden]> 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
thought
> 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
that
> 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
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