From: Geoff Leyland (gley001_at_[hidden])
Date: 2004-02-09 19:13:34
On 10/02/2004, at 12:14 PM, Jonathan Turkanis wrote:
> "Geoff Leyland" <gley001_at_[hidden]> wrote in message
> news:9EDC4024-5B52-11D8-B48C-000A95DB9BF6_at_ec.auckland.ac.nz...
>> Hi,
>>
>> Excuse me if this is already somewhere in boost - I haven't managed
> to
>> find it. Does anyone else think that an exception that you can
> write
>> to like a stream would be useful?
>> ...
>
> Have you seen
>
> http://www.boost.org/more/error_handling.html
>
> particularly item 4 ("Format the what() message o demand"), but also 3
> and 5?
>
> Jonathan
I have now, thanks, and in principle I agree with what it says.
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.
cheers,
Geoff