Re: Exception specifications unfortunate, and what about their future?
On Dec 10, 7:33 am, Geert-Jan Giezeman <ge...@cs.uu.nl> wrote:
JoshuaMaur...@gmail.com wrote:
I think I'm against checked exceptions as they exist in Java, though
I
don't know enough to conclude at this time. However, what I will do
is
pursue the following "concept / idea in progress" as my new
preferred
way of solving this static-checked exceptions dilemma, though it's
probably academic at this time for C++. (Maybe some cool new
language
could take this idea and run with it, or the next major revision to
C+
+.)
Proposal:
- The throws specification of a function can include the keyword
auto.
Ex:
void baz() throw(auto, std::bad_alloc);
- A function without an explicit C++ source throws specification is
equivalent to giving it a throws "auto" throws specification.
- When a function is compiled with a C++ source throws
specification,
that throws specification is added to the compiled object code. In
particular, "auto" is added to the compiled object code in the
throws
specification of the function.
- When the linker links object files together, it will create a call
graph. For each function with a C++ source throws specification with
"auto" (or no C++ source throws specification), it will traverse the
call graph down, figuring out every single function it can call,
directly or indirectly. It will then determine a minimal throws
specification for that function, and append that to any exceptions
in
the C++ source throws specification. For each function with a C++
source throws specification without "auto", if the linker finds that
an exception can be thrown which is not in the C++ source throws
specification, it will issue a diagnostic. (Note that this could
probably be optimized to something like a bottom up traversal of the
graph, from leafs to roots.)
Anyone have any comments or thoughts on its workability,
feasibility?
Any additions? Any glaring holes which I missed?
I like the direction you are taking: no unchecked exceptions and some
automatic way of keeping track of what can be thrown. I think the
workability would be ok, but I have my doubts about the feasability.
Given the following code (under the proposed extension):
void foo(int i) // 1
{
if (i<0) throw std::invalid_argument("negative argument");
}
void bar(int i) throw()
{
try {
foo(i); // 2
} catch (std::exception &) {
}
foo(i); // 3
}
Given that foo throws an exception itself, which of the following
declarations would be OK?
void foo(in) // nothing here
void foo(int) throw(auto)
void foo(int) throw(std::invalid_argument)
void foo(int) throw(std::exception)
So, does the compiler infer the exceptions thrown by a function?
You say that the linker infers the throws specification by traversing
the call graph. Now, in function bar, call 2) should not lead to any
problem with respect to the no-throw specification, because the (base
class of the) exception thrown by foo is caught. Call 3) should lead
to
a diagnostic. It seems that your scheme is a bit too simplistic to
deal
with this situation. The exception specification tracer should know
about try blocks and about the hierarchy of exceptions in order to do
its work. Especially in the case of dynamic loading, this may be
difficult.
Yes, it would have to know about try catch blows, throw statements,
etc. It would not be an easy change to implementations.
Alternatively, the compiler could help out as well. It could include
in the compiled object code
* The specified throws of function foo = exception_2.
* The actual throws of function foo = ((throws of function bar -
exception_1) union (throws of function baz) union (exception_2)) -
(exception_3).
The linker would not have to make any call graphs if the compiler gave
it this.
On Dec 10, 7:39 am, Martin Bonner <martinfro...@yahoo.co.uk> wrote:
On Dec 10, 2:48 am, JoshuaMaur...@gmail.com wrote:
[huge snip]
Anyone have any comments or thoughts on its workability,
feasibility?
Any additions? Any glaring holes which I missed?
It doesn't address the original Stroustrup counter example to
statically checked exceptions:
std::sqrt(double) is documented as throwing std::domain_error for
negative values. Now consider:
inline double hypot(double a, double b) throws()
{
return std::sqrt( a*a + b*b );
}
This function clearly won't ever throw domain_error, but how do you
tell the compiler that? I think to add statically checked exceptions
to C++, you have to add a "throw_cast" which tells the compiler that
the expression will not throw a certain type (or will throw a given
set of types). If the expression /does/ throw, then that is UB.
Similar examples can be constructed for push_back on a vector when you
have already allocated enough space.
Hmmm... Having worked with Java for a while, the same problem exists
there.
This is unlike the other attacks I've read in this thread on
statically checked exceptions (though I may have blanked out on this
one when I first read the thread). It's not arguing ease of use,
maintenance, or anything else like that. It's arguing that it's just a
bad idea to start with.
Let me try a thought experiment. Suppose you had some large chunk of
code which produced an input to a function foo() on an object bar.
bar::foo() is documented as returning an error code if the input is
invalid for the current state of the bar object. Now, you can
determine via code review that your code will never produce this
invalid input, and thus you argue that you do not need to check for
the error return code.
I see the previous paragraph as the moral equivalent of your argument
of "No statically checked exceptions because the programmer knows what
he is doing". C++ should let the programmer do what he wants when he
knows what he is doing, but generally we should prefer giving him
tools to prevent himself from accidentally shooting himself in the
foot, ex: type safety, and to bypass it type punning, void pointers,
etc.
In this case, suppose we know that this particular call to sqrt will
not throw an exception. In my scheme, if we do not deal with the
impossible exception, the compiler / linker will complain at us. When
it does, the programmer could put a try-catch (with an release assert
in the catch) to quiet the compiler on this impossible situation. (To
argue against any maintainability objections, if this happens
frequently for this function, the programmer could just write a small
wrapper over the function to catch and release-assert on any thrown
exceptions.)
I think that this statically checked exception scheme would be
exceedingly useful, and I think the counter-argument of Stroustrup is
probably rare enough that the programmer can handle these cases by
squelching the impossible exception with a try-catch-release-assert.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]