George <George@discussions.microsoft.com> wrote:
I hear some points to support exception specification is because,
only if developer could clearly list all the possible exceptions a
function may thrown, it is well designed function -- all exception
situations are thought.
List them in a comment next to the function declaration, or in the
documentation.
Realize that the compiler has to actually generate code to enforce
exception specification at runtime. If you know your function never throws
exceptions other than those on the list, by writing an exception
specification you force the compiler to generate dead code that you know
will never run. And if you know your function _will_ throw exceptions
outside the list, then what's the point of putting in an exception
specification that's essentially a lie?
If we do not have exception specification, and simply catch(...),
there may be some exceptions we (developer) never thought of in
design/implementation.
If there are exceptions you didn't think of, then you can't clearly list
all the possible exceptions a function may throw. By your own definition,
such a function is not well designed. So go back and design it better.
I don't see how catch(...) is helpful. What are you going to do in such a
handler, other than perhaps some cleanup and then rethrow?
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925