Re: Strongly checked exceptions: what we can learn from java experiences
On Jun 8, 4:28 pm, ThosRTanner <ttann...@bloomberg.net> wrote:
On Jun 2, 2:36 am, Joshua Maurice <joshuamaur...@gmail.com> wrote:
On May 30, 6:00 am, ThosRTanner <ttann...@bloomberg.net> wrote:
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 don't quite follow. It will compile regardless because it's well
formed code. Compilers will produce an executable on even the simplest
null pointer accesses.
That's not a null pointer access. That won't compile because you're
trying to write via a const pointer. No compiler will compile that,
even though the attempt to write via a const pointer can never be
executed.
I noted that the exception analysis should include all code, even
obviously "dead code", because the alternative is unworkable. Your
sqrt abs example is a trivial example, but there is no algorithm which
detect all such possible cases. Specifically, IIRC, there is no
algorithm which can detect all dead code. That would be equivalent to
solving the Halting problem. And if you can't solve this problem for
the general case, why even bother at all? IMHO, it would just surprise
the programmer - sometimes it catches it, and sometimes it doesn't -
all for little to no added benefit.
This currently happens to me in Java. AFAIK, there's some rules that
state certain kinds of dead code shall be a compiler error. Sometimes
I hit this nuisance when doing testing. Usually I placate the compiler
with something trivial like "if (true)". (I suppose I could just learn
whatever Eclipse keyboard shortcuts to comment out blocks of code, but
you should see my point that's it's next to useless to mandate some
kinds of data flow analysis but not others.)
I'm not mandating any data flow analysis. I'm saying that if
if (false) *const_ptr = value;
doesn't compile (which it doesn't)
then
void x(float x) throw()
{
sqrt(abs(x));
}
shouldn't compile (which it does).
I don't care that this one trivial case should have to be coded round.
Because the number of crashing errors in coding this would eliminate
would far exceed the effort put into fixing "can never happen" things.
Oh. I see. I didn't notice the "const". My post was silly.
Ok, so we agree that we ought to make the standard declare that the
following is ill-formed, even though it is impossible to execute that
code.
void func(char const *a, int n)
{
if (abs(n) < 0) *a = 'x';
}
Also, one pedantic note, That claim is technically untrue.
abs(INT_MIN) is undefined for 2s compliment ints. (In practice, it
returns INT_MIN.) The C++ standard directs to the C standard, and in
the draft I have lying around it's at 7.20.6.1 The abs, labs and llabs
functions / 2. It's possible that "abs(n) < 0" would evaluate to true.
Yes, I hate this too.
I fear I'm about to ask another stupid question. How is the next code
piece related to the above code piece?
void x(float x) throw()
{
sqrt(abs(x));
}
Are you trying to argue the following?
- sqrt and abs are both declared as "maybe throw"
- "throw()" ought to be statically checked
- thus the above code should fail to compile because the body
(potentially) throws exceptions not in the throws specification?
If not, then I am lost. If you are trying to argue that, then I would
simply direct to my posts else-thread where I think that requiring
throws specifications on each function is a bad idea (as evidenced by
Java), and I would prefer my crazy scheme with the linker if we're
going to do statically checked throws specifications.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]