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 that low resources will not be a problem?

Well, I have a use case in which it helps me, which I explained in the last post - and I can explain further if you like - and perhaps 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) On 10/02/2004, at 2:54 PM, Reece Dunn wrote:

Using a stringstream would be my approach to achieve this affect, but I wonder what would happen if the stream operation generated an exception? E.g.

throw( std::ostringstream() << "Error #" << 404 << weberror( 404 ));

I'm actually using it to replace the case where, lazy as I am, I couldn't be bothered creating a new exception class, and just threw a char *: throw "Couldn't open the file"; Which is certainly exception safe, and very mindful of limited resources, but when you're trying to open about 20 user specified files and dlls, not very informative. So throw streamy_exception() << "Couldn't open the file '" << file_name << "'"; is a world better for me. Yes, it uses lots of resources. Yes, the exception constructor and subsequent streaming could throw, but my experience has shown that the biggest danger is neither of these. What goes wrong is that I'm too lazy to write a really nice exception for every case, and so uninformative exceptions are thrown.

what if weberror thows an exception? Also, is ostringstream guaranteed not to throw an exception?

What about throw spiffy_web_exception(404, weberror(404)); It's not much different is it? You could call weberror() in the exception's what(), inside a try block, but if it did throw, what would you do? throw spiffy_web_error(404); then virtual const char *spiffy_web_error::throw(void) const throw() { static std::string temp; try { std::ostringstream os; os << "Error #" << error_number << weberror( error_number ); temp = os.str(); return temp.c_str(); } catch (...) { return "spiffy_web_error : couldn't work out what happened, sorry" } } The message in the final case doesn't give much useful information. Also, you can see in order to get a char * that will live beyond the scope of what you have to either: have something like a static temporary string-type thing lying around or strcpy os.str into some newed memory; make the ostringstream a member of the exception - and so have it constructed at the time you throw it - risking the double exception again; have a better idea? and also shows why sometimes it might, just might, be easier to go: std::cerr << s; rather than std::cerr << s.what();

Throwing an exception during the exception process is not a good idea!

It's not that bad - the program exits without giving a clear indication of what went wrong. If the alternative is to have the program exit without giving a clear indication of what went wrong, then that's probably ok. I do agree that you could throw an ostringstream though. The advantages I see of throwing an exception I see are You get to overload what(). You can extend the exception : throw streamy_web_error(404) << "Error #" << 404 << weberror( 404 ); (You could potentially disable the streamy part (make "<<" do nothing), and end up throwing an exception that spat out a readable error in a command line version, an exception containing just the error code and type information in (say) a windows version, and, to some extent, get some free documentation at the point of the error.) I'm also imagining that by using the format library and some kind of translation tool, you could probably fairly easily get translated versions of the text of your exception. I haven't played with the format library that much though. I'm certainly not advocating that everyone who uses exceptions should use such an exception. Those who can do better certainly should. Nor am I advocating that Boost libraries should throw such exceptions : I think it would be a very bad idea for Boost to put all that stream overhead into libraries that don't need it or to throw exceptions in english. However, if there are other people like me who write throw "oops. Something went wrong"; or even throw 1; in their own code, as I often did in the last days of my thesis, then maybe such a facility will help them a bit. Of course they could write such an exception themselves, but there are one or two tricks : you really do get problems if you try to return os.str.c_str() to an ostringstream in what()'s scope. cheers, Geoff

On 10/02/2004, at 5:00 PM, Jonathan Turkanis wrote:

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.

Yes, quite. I hope I'm not labouring a point too much here, but my experience is that what's usually wrong with error handling is that the library just exit()s when there's an error (which a lot of old fortran I've used did). It's also quite a lot of work to wrap information about an error up at the point at which it occurs, and then to extract it at some later moment and do something intelligent with it. Quite often, the "intelligent" thing that is done is to report an error to the user, and that error can quite often be reasonably well described at the point at which it happened. Throwing a streamy exception has small advantages over a const char * (you can add more information) and an ostringstream (you can catch it as a std::exception) and it lends itself to further extension. Notice that because I'm throwing an exception, *not* an ostringstream, nothing precludes one from also including information of more general interest in the exception.

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* ;-)

Yes. And in cases where you might get away with an int or const char *, something nicer might make things even easier. The question is: is this what Boost is about? Perhaps Boost shouldn't be encouraging programming like this, perhaps some users of Boost are writing clunky command like computational code. cheers, Geoff

On 10/02/2004, at 6:54 PM, Jonathan Turkanis wrote:

I think boost should encourage best practices, not practices which work acceptably only in limited circumstances without providing substantial benefits.

Fair call.

For miscellaneous errors, you can use one the standard exception classes, such as runtime_error, using a stringstream to format the results, if you like:

stringstream s; s << "somebody made " << x << " mistakes"; throw runtime_error(s.str());

This gives you the results you want, doesn't it? Is it really that inconvenient?

Oh, well I'm alright, because I'll go on using my streamy exception where I think it's warranted. Convenience is an interesting question though. To some extent (no offence to the authors of excellent libraries that I use a lot and am extremely grateful for) my use of boost::lambda and boost::bind amounts to avoiding the inconvenience of hand writing function objects - but I wouldn't want to live without them. Funny that gcc's runtime_error uses a string copy constructor that could potentially throw :-) cheers, Geoff

At Tuesday 2004-02-10 00:01, you wrote:

On 10/02/2004, at 6:54 PM, Jonathan Turkanis wrote:

...

I think boost should encourage best practices, not practices which work acceptably only in limited circumstances without providing substantial benefits.

Fair call.

...

For miscellaneous errors, you can use one the standard exception classes, such as runtime_error, using a stringstream to format the results, if you like:

stringstream s; s << "somebody made " << x << " mistakes"; throw runtime_error(s.str());

This gives you the results you want, doesn't it? Is it really that inconvenient?

Oh, well I'm alright, because I'll go on using my streamy exception where I think it's warranted.

Convenience is an interesting question though. To some extent (no offence to the authors of excellent libraries that I use a lot and am extremely grateful for) my use of boost::lambda and boost::bind amounts to avoiding the inconvenience of hand writing function objects - but I wouldn't want to live without them.

Funny that gcc's runtime_error uses a string copy constructor that could potentially throw :-)

what exception do you see it throwing (possibly) ?

cheers, Geoff

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"