Fwd: [boost] Re: Exceptions as streams

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