Boost logo

Boost :

From: Geoff Leyland (gley001_at_[hidden])
Date: 2004-02-09 23:37:31


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk