Java-like exception specifications
John the newbie
does anybody knows whether there's a C++ compiler which allows
(through a switch or something similar) to perform a compile time
control on exception specifications like Java compilers do? What I
want is to check in compile time if my code might lead to an
unexpected exception.
Thanks a lot,
John.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Sean Kelly
news:<102a8848.02020...@posting.google.com>...
> Hi guys,
>
> does anybody knows whether there's a C++ compiler which allows
> (through a switch or something similar) to perform a compile time
> control on exception specifications like Java compilers do? What I
> want is to check in compile time if my code might lead to an
> unexpected exception.
C++ does allow for exception specifications but they are a feature not
often used. For a full explanation, see Item 14 of Scott Meyers'
"More Effective C++." Basically, the compiler will not enforce
exception safety with functions that include no exception
specification. That is:
void foo() { throw some_error(); }
void bar() throw() { foo(); }
will compile just fine, but:
void foo() throw( some_error ) { throw some_error(); }
void bar() throw() { foo(); }
will not. Reason being that compilers have to allow you to use old
code that does not provide exception specifications. Even worse, in
the first situation, calling bar() will result in a "unexpected"
exception to be thrown, whose default behavior is to abort the
execution of the program.
Best practice IMO is not to use exception specifications as they are
misleading, and to assume that any function may throw any exception.
apm
> does anybody knows whether there's a C++ compiler which allows
> (through a switch or something similar) to perform a compile time
> control on exception specifications like Java compilers do?
Yes I know. No there isn't. This was discussed in USENET last November
in a thread started by me. See:
http://groups.google.com/groups?q=exception+stricter+checking+group:comp.lang.c%2B%2B.moderated+group:comp.lang.c%2B%2B.moderated&hl
=en&selm=d1a33011.0111250245.15027582%40posting.google.com&rnum=1
Also see my proposal at
http://www.andrewmarlow.co.uk/publications.html
Regards,
Andrew M.
Alexander Terekhov
John the newbie
Newsgroups: comp.lang.c++.moderated
Subject: Re: Java-like exception specifications
References: <102a8848.02020...@posting.google.com>
<721ff0b.02020...@posting.google.com>
NNTP-Posting-Host: 212.17.221.61
ken...@pacbell.net (Sean Kelly) wrote in message
news:<721ff0b.02020...@posting.google.com>...
[snip...]
> C++ does allow for exception specifications but they are a feature not
> often used. For a full explanation, see Item 14 of Scott Meyers'
> "More Effective C++." Basically, the compiler will not enforce
> exception safety with functions that include no exception
> specification. That is:
>
> void foo() { throw some_error(); }
> void bar() throw() { foo(); }
>
> will compile just fine, but:
>
> void foo() throw( some_error ) { throw some_error(); }
> void bar() throw() { foo(); }
>
> will not.
Well, I'm a newbie but not to the point you can give me such erroneus
information! ;) Both snippets compile well... my question was exactly
whether there's any C++ compiler which warns me that my code might
throw unexpected exceptions.
James Kanze
> does anybody knows whether there's a C++ compiler which allows
> (through a switch or something similar) to perform a compile time
> control on exception specifications like Java compilers do? What I
> want is to check in compile time if my code might lead to an
> unexpected exception.
Not that I know of, but I fear that any such switch would fill the
disk with warnings. The default in C++ is that a function without an
exception specification may throw anything, so any use of such a
function in another function will require a try block. And for the
most part, the standard library functions don't have exception
specifications (and the standard gives them a great deal of leeway to
throw implementation defined exceptions for unexpected conditions).
Personally, I don't like this, but I don't have any real alternative
to offer when templates are taken into considerations. Something like
std::vector<T>::push_back can throw std::bad_alloc, but it can also
throw anything the copy constructor or the assignment operator of T
can throw. How would you declare this?
Finally, I don't know why you cite Java on this, since Java's default
is hardly better than C++'s. In Java, only certain types of
exceptions are checked -- typically, the ones which wouldn't be
exceptions but return codes if the design were decent. Most of the
more useful exceptions are not checked either.
--
James Kanze mailto:ka...@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
-- Conseils en informatique orientée objet
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany, Tél.: +49 (0)69 19 86 27
Sean Kelly
news:102a8848.02020...@posting.google.com...
>
> ken...@pacbell.net (Sean Kelly) wrote in message
> news:<721ff0b.02020...@posting.google.com>...
>
> [snip...]
>
> > C++ does allow for exception specifications but they are a feature not
> > often used. For a full explanation, see Item 14 of Scott Meyers'
> > "More Effective C++." Basically, the compiler will not enforce
> > exception safety with functions that include no exception
> > specification. That is:
> >
> > void foo() { throw some_error(); }
> > void bar() throw() { foo(); }
> >
> > will compile just fine, but:
> >
> > void foo() throw( some_error ) { throw some_error(); }
> > void bar() throw() { foo(); }
> >
> > will not.
>
> Well, I'm a newbie but not to the point you can give me such erroneus
> information! ;) Both snippets compile well... my question was exactly
> whether there's any C++ compiler which warns me that my code might
> throw unexpected exceptions.
Sorry I thought the answer was implicit. No, the kind of exception
detection you mean would require extensive code parsing and no compilers do
that. All existing compilers do is look at the exception specifications of
functions that provide them and error if those specifications are
inconsistent. And VC++ (and a number of other compilers) doesn't do any
exception spec. enforement at all (at least version 6).
Sean
Alexander Terekhov
> Newsgroups: comp.lang.c++.moderated
> Subject: Re: Java-like exception specifications
> References: <102a8848.02020...@posting.google.com>
> <721ff0b.02020...@posting.google.com>
> NNTP-Posting-Host: 212.17.221.61
>
> ken...@pacbell.net (Sean Kelly) wrote in message
> news:<721ff0b.02020...@posting.google.com>...
>
> [snip...]
>
> > C++ does allow for exception specifications but they are a feature not
> > often used. For a full explanation, see Item 14 of Scott Meyers'
> > "More Effective C++." Basically, the compiler will not enforce
> > exception safety with functions that include no exception
> > specification. That is:
> >
> > void foo() { throw some_error(); }
> > void bar() throw() { foo(); }
> >
> > will compile just fine, but:
> >
> > void foo() throw( some_error ) { throw some_error(); }
> > void bar() throw() { foo(); }
> >
> > will not.
>
http://groups.google.com/groups?as_umsgid=c29b5e33.0202080850.6925a5%40posting
.google.com
http://groups.google.com/groups?as_umsgid=3C6393BD.E56764E5%40web.de
regards,
alexander.
Johan Johansson
>>does anybody knows whether there's a C++ compiler which allows
>>(through a switch or something similar) to perform a compile time
>>control on exception specifications like Java compilers do? What I
>>want is to check in compile time if my code might lead to an
>>unexpected exception.
>>
>
> Not that I know of, but I fear that any such switch would fill the
> disk with warnings. The default in C++ is that a function without an
> exception specification may throw anything, so any use of such a
> function in another function will require a try block. And for the
> most part, the standard library functions don't have exception
> specifications (and the standard gives them a great deal of leeway to
> throw implementation defined exceptions for unexpected conditions).
Unfortunately the lack of enforcement makes exception specifications
useless except as a neat way of terminating your program (just throw
something outside of the specification), which doesn't exactly encourage
the use of them. This in turn gives more functions without exception
specifications and so on. I think a compiler switch could be useful to
check at least reasonably well-behaved portions of the code. But I agree
that the lack of specifications in the standard library is going to be a
problem for any such attempt.
> Personally, I don't like this, but I don't have any real alternative
> to offer when templates are taken into considerations. Something like
> std::vector<T>::push_back can throw std::bad_alloc, but it can also
> throw anything the copy constructor or the assignment operator of T
> can throw. How would you declare this?
The compiler is already instantiating the template. You are for instance
getting different return types or argument types for functions depending
on the types used in the instantiation. It only seems logical that it
would also add all possible exceptions thrown to the specification. This
would mean that the template shouldn't specify any exceptions that it
doesn't throw itself. This would naturally only work when instantiating
with a well-behaved type that has exception specifications for the
operations used in the template, but I think that it is unreasonable to
expect anything else with the "no specifier"-loophole.
> Finally, I don't know why you cite Java on this, since Java's default
> is hardly better than C++'s. In Java, only certain types of
> exceptions are checked -- typically, the ones which wouldn't be
> exceptions but return codes if the design were decent.
It may not cover all cases, but at least it covers *some* unlike the
"give up"-approach taken by C++. I was able to write comments long
before there was a throw clause, the main difference being that they
didn't silently terminate my program if anyone below in the call-chain
misbehaved.
Your claim that only certain kinds of exceptions are checked has things
completely backwards. Only certain kinds of exceptions are *not*
checked. Which exceptions should be of which kind is a design issue,
where some of them have already been made for you by the Java library.
Typically exceptions that can always be thrown, such as whatever the
analogue to std::bad_alloc is or class loading errors, are of the kind
that you don't need to declare since these issues are supposedly handled
by the JVM.
C++ has an edge on Java in many respects, but the use of exception
specifications is not one of them.
j
David Abrahams
"Johan Johansson" <joh...@ipunplugged.com> wrote in message
news:3C667C71...@ipunplugged.com...
> James Kanze wrote:
> > Finally, I don't know why you cite Java on this, since Java's default
> > is hardly better than C++'s. In Java, only certain types of
> > exceptions are checked -- typically, the ones which wouldn't be
> > exceptions but return codes if the design were decent.
>
>
> It may not cover all cases, but at least it covers *some* unlike the
> "give up"-approach taken by C++. I was able to write comments long
> before there was a throw clause, the main difference being that they
> didn't silently terminate my program if anyone below in the call-chain
> misbehaved.
>
> Your claim that only certain kinds of exceptions are checked has things
> completely backwards. Only certain kinds of exceptions are *not*
> checked. Which exceptions should be of which kind is a design issue,
> where some of them have already been made for you by the Java library.
> Typically exceptions that can always be thrown, such as whatever the
> analogue to std::bad_alloc is or class loading errors, are of the kind
> that you don't need to declare since these issues are supposedly handled
> by the JVM.
In what sense do you mean that out-of-memory is "handled by the JVM?" if a
function throws that exception in Java and you don't handle it, your app
will terminate just as any C++ app will. There's no magic in the Java EH
model.
> C++ has an edge on Java in many respects, but the use of exception
> specifications is not one of them.
No, but the fact that C++'s standard library doesn't force you to infect
your program with them is a big advantage. Java programmers I know waste
countless hours managing their exception-specifications, and the unchecked
exceptions were introduced specifically because dealing with checked
exceptions causes such a maintenance burden with comparatively little
benefit in terms of program robustness.
-Dave
Johan Johansson
>>Typically exceptions that can always be thrown, such as whatever the
>>analogue to std::bad_alloc is or class loading errors, are of the kind
>>that you don't need to declare since these issues are supposedly handled
>>by the JVM.
> In what sense do you mean that out-of-memory is "handled by the JVM?" if a
> function throws that exception in Java and you don't handle it, your app
> will terminate just as any C++ app will. There's no magic in the Java EH
> model.
Sure. What I ment was just that memory management in general is outside
the control of the program. In this case it would be better to say that
it detects the lack of memory, which may happen at any time but rarely does.
>>C++ has an edge on Java in many respects, but the use of exception
>>specifications is not one of them.
> No, but the fact that C++'s standard library doesn't force you to infect
> your program with them is a big advantage. Java programmers I know waste
> countless hours managing their exception-specifications, and the unchecked
> exceptions were introduced specifically because dealing with checked
> exceptions causes such a maintenance burden with comparatively little
> benefit in terms of program robustness.
If they are wasting "countless hours" I suspect they are doing something
wrong. Of course making sure that you pass any check is going to take
*some* time, but I think the appropriate questions are "how much time"
and "what do I gain from doing so". After all, it could be argued that
C++ programmers "waste countless hours" managing their types instead of
writing code that does actual work, but I don't think anyone is in
favour of getting rid of the type checks a C++ compiler performs.
j
Alexander Terekhov
>
> >>does anybody knows whether there's a C++ compiler which allows
> >>(through a switch or something similar) to perform a compile time
> >>control on exception specifications like Java compilers do? What I
> >>want is to check in compile time if my code might lead to an
> >>unexpected exception.
> >>
> >
> > Not that I know of, but I fear that any such switch would fill the
> > disk with warnings. The default in C++ is that a function without an
> > exception specification may throw anything, so any use of such a
> > function in another function will require a try block. And for the
> > most part, the standard library functions don't have exception
> > specifications (and the standard gives them a great deal of leeway to
> > throw implementation defined exceptions for unexpected conditions).
>
>
> Unfortunately the lack of enforcement makes exception specifications
> useless except as a neat way of terminating your program (just throw
> something outside of the specification),
What do you mean? The ultimate "enforcement" comes at run-time
(think of system generated exceptions for "misbehaved" programs,
for example). Yes, no compiler/linker that I know/use WARNS me
about *perhaps* missing "catche"s, but that's just warnings,
not enforcement, oder? To me, if someone writes "throw-expression"
he or she actually expects that someone will HANDLE it/RECOVER,
and whether its some program's catch clause or higher level
recovery "system" on top of terminate()->abort() or alike
(catch(...) { return INTERNAL_FAILURE; } is less ROBUST, IMHO
but might work well enough/be needed as well), is a another
question/problem to solve. And program state safety on the way
to the handler (if any) is completely different problem,
which if possible, should be solved *without* any catch/rethrow;
and C++ is *great* in this respect having/providing AUTO objects.
> which doesn't exactly encourage
> the use of them.
Well, I think that "throws()" ES is actually a pretty useful thing!
And personally, I use it quite often! ;-)
> This in turn gives more functions without exception
> specifications and so on. I think a compiler switch could be useful to
> check at least reasonably well-behaved portions of the code.
Well, I guess it would need a kind of #pragma unexpected_exception_push()/
#pragma unexpected_exception_pop or something like that to suppress
USELESS warnings to be useful, for example:
void blabla_operation() throws( thread_cancel );
MyAutoObject::~MyAutoObject() throws()
{
// Disable thread cancellation state
//...
// Says that compiler/linked should not warn
// about "uncatched" thread_cancel exception
#pragma unexpected_exception_push( thread_cancel )
blabla_operation();
// Restores the "list" of unexpected exceptions,
// perhaps "..." (everything) could actually be a
// default ;-)
#pragma unexpected_exception_pop
// Restore thread cancellation state
//... (perhaps just another auto-object's destructor)
}
> But I agree
> that the lack of specifications in the standard library is going to be a
> problem for any such attempt.
Why?
Well, what perhaps could be useful, IMHO, is a sort of
OPEN-ENDED exception-"specification":
template< ... >
void blabla_operation( ... ) throws( thread_cancel,...);
Which would basically say to the client: Hey, I am a
cancellation point, which could throw thread_cancel
(unless you disable cancellation), PLUS anything else,
for details -- see my impl! ;-)
This would have nothing to do with "enforcement",
but could still be useful, not affecting the
compiler's/linker's ability to warn me of perhaps
unhandled exceptions/missing catch clauses assisted
by something along the lines of "unexpected" pragmas
to suppress useless warnings.
regards,
alexander.
James Kanze
news:<a46jfg$99d$1...@bob.news.rcn.net>...
> > C++ has an edge on Java in many respects, but the use of exception
> > specifications is not one of them.
> No, but the fact that C++'s standard library doesn't force you to
> infect your program with them is a big advantage.
Yes and no. The that the C++'s standard library doesn't insist on
exceptions where they aren't appropriate is a big advantage. Having
working, controlled exception specifications would IMHO also be a nice
advantage. Neither language does, but at least C++ doesn't pretend to
(and has the excuse of templates -- as a I said, I don't have a good
answer to that one).
> Java programmers I know waste countless hours managing their
> exception-specifications, and the unchecked exceptions were
> introduced specifically because dealing with checked exceptions
> causes such a maintenance burden with comparatively little benefit
> in terms of program robustness.
We must know different Java programmers; the ones I know derive all of
their exceptions from RuntimeException, and never declare anything:-).
Just like in C++. If Java wants to claim verified exception
specifications, they're going to have to do something to prevent
anyone outside of package java.lang from deriving from
RuntimeException; otherwise, it's no different from C++.
With regards to the problem you mention, of course, the Java weakness
there is related to the fact that you almost have to use exceptions,
even when they are not appropriate, since there are no out parameters,
and you can only return one thing.
--
James Kanze mailto:ka...@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
-- Conseils en informatique orientée objet
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany, Tél.: +49 (0)69 19 86 27
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
David Abrahams
> David Abrahams wrote:
> >>Typically exceptions that can always be thrown, such as whatever the
> >>analogue to std::bad_alloc is or class loading errors, are of the kind
> >>that you don't need to declare since these issues are supposedly handled
> >>by the JVM.
>
> > In what sense do you mean that out-of-memory is "handled by the JVM?" if
a
> > function throws that exception in Java and you don't handle it, your app
> > will terminate just as any C++ app will. There's no magic in the Java EH
> > model.
>
>
> Sure. What I ment was just that memory management in general is outside
> the control of the program. In this case it would be better to say that
> it detects the lack of memory, which may happen at any time but rarely
does.
And this distinguishes out-of-memory from other exceptions somehow?
> >>C++ has an edge on Java in many respects, but the use of exception
> >>specifications is not one of them.
>
>
> > No, but the fact that C++'s standard library doesn't force you to infect
> > your program with them is a big advantage. Java programmers I know waste
> > countless hours managing their exception-specifications, and the
unchecked
> > exceptions were introduced specifically because dealing with checked
> > exceptions causes such a maintenance burden with comparatively little
> > benefit in terms of program robustness.
>
>
> If they are wasting "countless hours" I suspect they are doing something
> wrong. Of course making sure that you pass any check is going to take
> *some* time, but I think the appropriate questions are "how much time"
> and "what do I gain from doing so".
*precisely*
I contend that you gain comparatively little from knowing exactly which
exceptions can be thrown (a weak guarantee that you can give a somewhat
meaningful error report -- inheritance means you don't even know what type
you really have). I usually hate when people post links to previous articles
this way, but in this case I've been through the argument so many times...
http://groups.yahoo.com/group/boost/message/22807
http://makeashorterlink.com/?Z1AF6166
and the associated threads lay it out in all its gory detail
> After all, it could be argued that
> C++ programmers "waste countless hours" managing their types instead of
> writing code that does actual work, but I don't think anyone is in
> favour of getting rid of the type checks a C++ compiler performs.
It's a false analogy, because a program's reliability is mostly related to
the integrity of its state. Enforcing exception types doesn't do much to
maintain that, while static type checking does. That's explained in more
detail in the links above.
-Dave
Alexander Terekhov
[...]
> > If they are wasting "countless hours" I suspect they are doing something
> > wrong. Of course making sure that you pass any check is going to take
> > *some* time, but I think the appropriate questions are "how much time"
> > and "what do I gain from doing so".
>
> *precisely*
>
> I contend that you gain comparatively little from knowing exactly which
> exceptions can be thrown (a weak guarantee that you can give a somewhat
> meaningful error report -- inheritance means you don't even know what type
> you really have). I usually hate when people post links to previous articles
> this way, but in this case I've been through the argument so many times...
>
> http://groups.yahoo.com/group/boost/message/22807
<from that previous article>
: But much more importantly, #5 - the type of the exception object almost
: never changes anything about the correctness of your program state!
Yes (presuming sanity of "commit" operations -- should
better be "throw()", IMHO... and if you just refuse to
consider "unexpected" system generated "misbehaved"
faults/exceptions as an indication of completely
broken/corrupted program state deserving to end up
in abort()->"core dumped" *ASAP*).
: All it
: does is give you some information to use for user-friendly error reporting.
No, IMO -- details/the way I see it, follow below.
> http://makeashorterlink.com/?Z1AF6166
>
> and the associated threads lay it out in all its gory detail
^^^^^^^^^^^^^^^^^^
I think that
http://groups.yahoo.com/group/boost/message/23195
IS closely associated with your first link/thread...
Therefore I'll try to address a few points,
since back then I was somewhat distressed by
your -mod/dwa's "ALL CAPS == shouting" remark.
: If you are writing C++ code that gets called from another language, you
: generally can't let an exception propagate out of your outer-level function.
: If you don't happen to know the exception, at least you can report /some/
: error. If you don't catch(...), you will crash your caller unless you happen
: to know (a base of) every exception type that can propagate into your
: function.
To me, this is just an example that shows how to RETHROW
an exception and let someone else further down handle it...
loosing all meaningful information via converting unknown/
unexpected exception to some generic "INTERNAL_FAILURE"
return/status code. That might be acceptable/needed, but
in no way shows that exception type knowledge/presence of
proper catch handlers (that do RECOVERY... or it is done
by some higher level recovery "system" perhaps just sitting
on top of terminate()->abort()) is useless, IMHO.
: For any given exception type you can name, I'll say, "no, it shouldn't be
: eaten - a fully descriptive error report should be generated somewhere". The
: reason to catch(...) without rethrowing is to deal with the exceptions you
: didn't account for. For those, the best you can do is report "an error
: occurred",
And what should the user do with such "very descriptive"[1]
message? Hit RETRY or CANCEL button? Well, in some
situations it might be acceptable, but in NO way[2] for:
: some applications, like the life support in my
: spacecraft, continuing could be much better than terminating at this point.
<!>
regards,
alexander.
[1] To me, the best information in such situation is
"core dump", "crash-dump", "CEEDUMP", which keeps
complete program state at the point of unexpected
unknown (in the sense that program does NOT know
how to recover) failure.
[2] Well, if *I* will ever have to go to the intensive-care
(I have no personal spacecrafts or things like that with
live-support systems), I would really hope that in the
situation of unexpected/unknown failure, my life support
system will perform FAILOVER/RECYCLED-RETRY eventually/soon
getting rid of "bad" input (if error continues to show up
even after "full recycling") -- that is what I mean with
higher level recovery "system", PRESERVING "dump" infos
so that this problem could be easily debugged/solved
and removed in the next release.