Dave Abrahams wrote in article <79se66$1fl$1@news.harvard.net>...
>[...]
>This scheme breaks down as soon as anything in namespace SQLAccess wants to
>use a standard library function which is allowed to throw. Then you have to
>find some way to translate every possible exception into a SQLException. It
>seems like it would exhibit all of the same maintenance problems that
>ordinary exception-specifications do, but by limiting the number of places
>where exception-specifications were actually written, might reduce the
>number of places in the source code which had to be inspected. You're still
>left with a maintenance hassle and the danger of unexpected termination in
>situations which might have been handled perfectly well otherwise. I don't
>think it changes anything fundamentally.

I guess I share the dislike of the original poster for having most
functions beeing able to throw just about anything they like.
Still every time I thought about a set of coding rules for throw
specifications to be used in a new project I run into that scenario
where you find yourself adding many exceptions to these specifications
just to stop your app from crashing because of uncaught exceptions.

What I usually do is limiting the number of exception types by
catching std::exception and the like at subsystem boundaries and add
their info to an exception specific for that subsystem. This also
solves the problem that if you have a service A used by a service B
you don't want users of A having to deal with B's exceptions. I
even wrote a set of macros to do this automatically.
Doing this I keep thinking whether it would be a good idea to somehow
introduce such a semantic into the exception mechanism.
What I'm thinking of goes along the line of converting an exception A
to an exception B if B has a non-explicit constructor for a single
argument of type A and the throw specification would allow only
exceptions of type B. I'm not sure if this implicit conversion
would be good, but probably one could think of a more wanted-only
mechanism. Almost anything would be easier that the long list of
catch statements at the end of all these functions.

Any ideas? What are the things I didn't think of? Syntax?

>-Dave



  Schobi

Sorry if you feel like I'm kinda hijacking this thread.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]