On Fri, 2003-11-07 at 06:27, Shawn Masters wrote: > The issue you raised wasn't specifically one of a throws, but a > return value. I didn't read the code, but the comment. What I was > referring to is there is no way for a function to return a value once it has > thrown any exception. The stack has had one or more call popped off of it. > No locality for a return value exists anymore for any of those calls.
I agree with your explanation of throwing an exception. See below for a
simplified version of the function.
> If what it is complaining about is a NotImplemented exception being
> thrown but not specified I think that is a fair thing to do in code. Do you
> really want to carry around handler code through out the library to catch
> the NotImplemented or just get a compiler warning? I'd live that warning
> very happily, at least until I have completed implementation :-).
What the compiler is complaing about is the fact we have a function that
returns a type but also throws an exception.
bool A () {
throw B();
}
In this example we have what started this thread of communication. The
function A throws the exception B as a part of is declaration. This
particular function has two exit points. One is if everything goes well
it returns a bool and the other is if there is a problem it throws an
exception.
What we see here is that is a compiler will be expecting an 'bool' type
to be return. So to change the function a bit I would need to do:
bool A () throw (B)
{
throw B ();
return true;
}
This function now does all the compiler needs. Its weird as Wei said
because logically we should not need to have the 'return true' because
the compiler should be smart enough. Alternatively we should not need to
have the 'bool' in the first place. If we don't return anything then do
not have a type. Unfortunately a simple change in return type makes the
whole thing break:
class C {
virtual bool A () = 0;
}
class D : public C {
virtual bool A () {
.. do work ..
return true;
}
}
class E : public C {
virtual bool A () {
throw B ();
}
}
This is similar to what is happening in pubkey.h. The class E must
implement the function A with the return type of bool. Yet it does not
return it. So changing the bool to a void causes me to violate the rule
to implement function A () as class C has it.
So while asserts enable us to find out errors in the crypto++ library I
agree that they should be remove before a release once the library has
been tested thoroughly. The return types of functions need to be
reconsidered or honored if the function does nothing but throw an
exception. Function declarations should report that they throw the
exception so that an application written to them can catch these
run-time exceptions.
As I am learning C++ I am trying to apply it. I learn hands on mainly.
So as I use crypto++ for a project I am trying to contribute these
'janitor' fixes to help Wei out. I hope this is clear. My intention is
to help clean up the the little things enabling others to implement the
deepr things.
Stephen
--
Stephen Torri
GPG Key: http://www.cs.wustl.edu/~storri/storri.asc
signature.asc
Description: This is a digitally signed message part
