On 10/02/2004, at 2:36 PM, Jonathan Turkanis wrote:
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
low resources will not be a problem?
Well, I have a use case in which it helps me, which I explained in
last post - and I can explain further if you like - and perhaps
"Geoff Leyland" <gley001@ec.auckland.ac.nz> wrote in message news:F830594E-5B79-11D8-B48C-000A95DB9BF6@ec.auckland.ac.nz... that the there
are others.
I think that for testing and correctness Boost.Test type things and and assertions are the right tools.
I guess I am using it in a case: where I judge that low resources will not be a problem; where, if an another exception occurs in generating the exception, well, bummer; where it's not worth spending time on a nicer mechanism; where I would like a semi-explanatory error message to be printed on the console or saved; where I do want the option of continuing with something (the next test), but I'm not really interested in rectifying the error.
In my particular case, as I said, the errors usually come from the user not getting an input file quite right (parseable, but not containing all the information I later need)
I got that part. I agree that there are times when the convenience of using strings (or streams) might outweigh the other disadvantages we discussed. But I think people trying to write reusable code will be reluctant to define exceptions that are only appropriate for limited circumstances. After all, part of the justification for introducing exceptions was that code which is in a position to detect errors often does not how to handle them appropriately, and some of the conditions you mention above sound like judgement that the programmer trying to handle exceptions might be in a better to make than the programmer wri ting the code which throws the exceptions. For small programs written by one person these issues are not so important. (These are also the cases where you can get away with thowing int or const char* ;-) Best Regards, Jonathan