Re: Strongly checked exceptions: what we can learn from java experiences
On May 28, 2:27 am, Andrew <marlow.and...@gmail.com> wrote:
Just came across an interesting article in the java lobby:http://java.dzone.com/articles/tragedy-checked-exceptions
This is not the only article that basically says "java tried to
implement checked exceptions but the experiment failed". I think this
should tell us C++ers that even if we could overcome the technical
obstacles to implementing checked exceptions (and this is difficult)
we would not want the result!
Ignoring for the moment the fact that the compiler *can* check whether
or not an exception is thrown is permissible from the throw spec, one
thing that confuses me about the arguments that result from this is
why it is necessary for the compiler to check all paths to see if you
throw an exception, quoting sqrt(abs(n)) which can "never" throw an
exception.
I can't help feeling the proponents of this argument should require it
be applied to const as well, for consistency.
After all,
void func(char const *a, int n)
{
if (abs(n) < 0) *a = 'x';
}
should compile, because obviously the code can never execute.
I still come back to the issue that this is runtime checked, and even
noexcept is runtime checked. And in the situation I'm in, this is
worse than useless.
Throwing an exception not in your throw list is breaking your
interface guarantee (like altering a const object or not returning a
result but dropping off the end of a function), can be detected and
should not compile. The cost of a try round the sqrt above is going to
be a few lines of C++ and very little assembler (and possibly the
opportunity to check your CPU is in danger of self-immolation)
I like Joshua's suggestion that there be places where the interface
must be checked, and that can be done at link time. Though as far as I
can see once you involved sqrt, at some point someone has to check for
whatever exception can be thrown.
As for microsoft compatibility, I suspect *a* solution would be for
the 'system' to ensure that these exceptions were invisible to the
user (as would be needed for the linux 'thread terminate' exception).
Both of those actually need to bypass catch (...) or really bad things
happen. (I can vouch for the problems caused by catch ... on linux).
There's only one reason I can think of for catching the m/s ones and
that's to dump status before terminating. And I'm not sure that's
particular wise of safe.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]