On 10/02/2004, at 12:14 PM, Jonathan Turkanis wrote:
"Geoff Leyland" <gley001@ec.auckland.ac.nz> wrote in message news:9EDC4024-5B52-11D8-B48C-000A95DB9BF6@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