Why do some code bases don't use exceptions?
krel
source projects or proprietary company code - deliberately choose not
use exceptions in their C++ code. The only example I can come up with at
the moment is are the Google C++ guidelines however, I've seen that
notions expressed in various places.
What are some reason that a project would choose not to use C++ exceptions?
krel
Ian Collins
Lack off, or poor compiler support.
--
Ian Collins
James Kanze
Today? Except possibly for very small embedded systems. Fear,
uncertainy and doubt about compiler support, maybe, but
exceptions are probably more stable than templates or RTTI
today.
Interoperatability with C would seem to me to be a more
significant reason. If an entire project is written in C++, I
don't see any real problem, but if you have C++ functions called
from C, and vice versa, you might want to pay attention.
It would also be interesting to know just what role these
guidelines play within Google. They don't seem very
appropriate; several of them actually violate best established
Any complex initialization should go in an explicit Init()
method. practice ("Any complex initialization should go in an
explicit Init() method", for example). Google certainly has
some exceptionally competent C++ programmers, but they don't
seem to have been involved here.
--
James Kanze
Bo Persson
Google also has tons of old code that was written without proper
support for exceptions. That's their main reason for not using it -
legacy code!
Bo Persson
James Kanze
That's a good point. Exceptions when code isn't exception safe
are a sure recepe for disaster, and code written before
exception safety was known or understood generally won't be
exception safe.
--
James Kanze
Ian Collins
> On Nov 17, 7:08 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> krel wrote:
>>> I've seen it mentioned in several places that some code
>>> bases - open source projects or proprietary company code -
>>> deliberately choose not use exceptions in their C++ code.
>>> The only example I can come up with at the moment is are the
>>> Google C++ guidelines however, I've seen that notions
>>> expressed in various places.
>
>>> What are some reason that a project would choose not to use
>>> C++ exceptions?
>
>> Lack off, or poor compiler support.
>
> Today? Except possibly for very small embedded systems. Fear,
> uncertainy and doubt about compiler support, maybe, but
> exceptions are probably more stable than templates or RTTI
> today.
I hope they have updated it now, but up to a couple of years ago the
Green Hill C++ compiler had a really poor exception implementation. So
bad we had to remove exceptions from our code.
--
Ian Collins
krel
>
> Today? Except possibly for very small embedded systems. Fear,
> uncertainy and doubt about compiler support, maybe, but
> exceptions are probably more stable than templates or RTTI
> today.
I probably should have added RTTI and templates to my original question
but I as I understand from your answer the main reasons for companies
not to use exceptions, templates or RTTI are:
1) Lack of compiler support
2) Does not integrate well with old code
Is that right? What I mean is that the reasons are not related to the
actual functionality of the feature, as in "X is a broken and badly
designed feature".
krel
Paavo Helde
september.org:
> James Kanze wrote:
>
>>
>> Today? Except possibly for very small embedded systems. Fear,
>> uncertainy and doubt about compiler support, maybe, but
>> exceptions are probably more stable than templates or RTTI
>> today.
>
> I probably should have added RTTI and templates to my original question
> but I as I understand from your answer the main reasons for companies
> not to use exceptions, templates or RTTI are:
>
> 1) Lack of compiler support
> 2) Does not integrate well with old code
>
> Is that right?
(1) might be an issue, but actually it should not, after having the C++
standard around for more than 10 years already. Regarding (2), RTTI and
templates are local features, so the integration should be no big
concern.
> What I mean is that the reasons are not related to the
> actual functionality of the feature, as in "X is a broken and badly
> designed feature".
In C++, there are surprisingly few "broken and badly designed features".
Non-empty exception specifications are one example, the "most-vexing-c++-
parse" another. The latter was kept for C compatibility, but I strongly
suspect the amount of C code saved this way is very close to zero.
Regarding Google, maybe they might have banned exceptions because of the
run-time overhead (just guessing). Throwing exceptions is notoriously
slow, so they should not be used unless something goes very wrong - but
for a 24/7 service like Google nothing should go wrong ever, so no need
for exceptions, right?
Cheers
Paavo
Shaun Deacon
> I probably should have added RTTI and templates to my original question
Another reason could be wanting statically built executables (There
are problems trying to link libstdc++ statically when compiling with g+
+ for example). The following link gives some detailed background :
http://www.trilithium.com/johan/2005/06/static-libstdc
best regards,
Shaun
Greg Herlihy
> What are some reason that a project would choose not to use C++ exceptions?
Because the program (or more likely, the library) has no exceptional
states.
Greg
James Kanze
> krel <k...@example.invalid> wrote innews:hduq8e$4f9$1...@news.eternal-
> september.org:
> > James Kanze wrote:
> >> Today? Except possibly for very small embedded systems.
> >> Fear, uncertainy and doubt about compiler support, maybe,
> >> but exceptions are probably more stable than templates or
> >> RTTI today.
> > I probably should have added RTTI and templates to my
> > original question but I as I understand from your answer the
> > main reasons for companies not to use exceptions, templates
> > or RTTI are:
> > 1) Lack of compiler support
> > 2) Does not integrate well with old code
> > Is that right?
> (1) might be an issue, but actually it should not, after
> having the C++ standard around for more than 10 years already.
Yes and no. How many compilers do you know that implement
standard conforming templates (including export)? It is still
an issue.
In the end, you weigh the advantages and the disadvantages, and
make a choice. Not using std::vector, and having to use
<generic.h> for your own generic classes, makes banning
templates completely a non-starter, regardless of how poorly
they are (typically) implemented.
> Regarding (2), RTTI and templates are local features, so the
> integration should be no big concern.
Exactly. The "existing code" argument mainly affects
exceptions, and not much else.
> > What I mean is that the reasons are not related to the
> > actual functionality of the feature, as in "X is a broken
> > and badly designed feature".
> In C++, there are surprisingly few "broken and badly designed
> features".
That's very arguable. The question isn't so much whether C++
does it right; it's usually a question of other languages not
supporting it at all.
> Non-empty exception specifications are one example,
Broken and badly designed, or simply a more or less good
solution without a problem?
> the "most-vexing-c++- parse" another. The latter was kept for
> C compatibility, but I strongly suspect the amount of C code
> saved this way is very close to zero.
Are you kidding? Take a look at any of the C headers on your
machine. How many systematically use "extern" before function
declarations, and how many just count on the fact that a
function declaration is always "extern", unless specified
otherwise.
> Regarding Google, maybe they might have banned exceptions
> because of the run-time overhead (just guessing). Throwing
> exceptions is notoriously slow, so they should not be used
> unless something goes very wrong - but for a 24/7 service like
> Google nothing should go wrong ever, so no need for
> exceptions, right?
If something truely goes wrong, you should have an assertion
failure, not an exception. Exceptions are for things that
exceptionally occur:-). Seriously, exceptions are the preferred
solution when the error is expected, but very infrequently, and
cannot reasonably be handled locally, by the calling function.
(Depending on context, I imagine that something like a dropped
connection could be reasonably reported by an exception. And it
would certainly be unrealistic for Google to expect never to see
one of those.)
--
James Kanze
James Kanze
> On Nov 17, 11:37 am, krel <k...@example.invalid> wrote:
> > I probably should have added RTTI and templates to my
> > original question
> Another reason could be wanting statically built executables
> (There are problems trying to link libstdc++ statically when
> compiling with g++ for example). The following link gives
> some detailed background :
> http://www.trilithium.com/johan/2005/06/static-libstdc
Despite the author's erroneous conclusions, that paper actually
explains why you should always link libstdc++ statically.
--
James Kanze
Brian
> On Nov 17, 7:08 am, Ian Collins <ian-n...@hotmail.com> wrote:
>
> > krel wrote:
> > > I've seen it mentioned in several places that some code
> > > bases - open source projects or proprietary company code -
> > > deliberately choose not use exceptions in their C++ code.
> > > The only example I can come up with at the moment is are the
> > > Google C++ guidelines however, I've seen that notions
> > > expressed in various places.
> > > What are some reason that a project would choose not to use
> > > C++ exceptions?
> > Lack off, or poor compiler support.
>
> Today? Except possibly for very small embedded systems. Fear,
> uncertainy and doubt about compiler support, maybe, but
> exceptions are probably more stable than templates or RTTI
> today.
>
> Interoperatability with C would seem to me to be a more
> significant reason. If an entire project is written in C++, I
> don't see any real problem, but if you have C++ functions called
> from C, and vice versa, you might want to pay attention.
>
I'm not sure why you say "vice versa." If you have C functions
called from C++, what's the problem? You just check the return
code and throw or proceed.
I've been trying to figure out what I should do with exceptions
and return codes for years. Currently I'm trying to support
both, but it is difficult to do so well. Most libraries I can
think of offer one or the other. Boost just uses exceptions
I think. I'm leaning toward dropping support for return codes.
> It would also be interesting to know just what role these
> guidelines play within Google. They don't seem very
> appropriate; several of them actually violate best established
> Any complex initialization should go in an explicit Init()
> method. practice ("Any complex initialization should go in an
> explicit Init() method", for example).
It looks like you still need to get some furniture.
Brian Wood
http://webEbenezer.net
Jorgen Grahn
...
> Regarding Google, maybe they might have banned exceptions because of the
> run-time overhead (just guessing). Throwing exceptions is notoriously
> slow,
Says who? Maybe you're right, for some value of "notoriously", but
I'm asking because that's a statement which gets thrown around a lot
with no data to back it up.
> so they should not be used unless something goes very wrong - but
> for a 24/7 service like Google nothing should go wrong ever, so no need
> for exceptions, right?
(I'm assuming you're not joking)
Flawed logic. If nothing should go wrong, the alleged slowness of
throwing and catching is irrelevant, and no longer a reason to avoid
exceptions.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Richard Herring
<6168959f-a70f-47e9...@s31g2000yqs.googlegroups.com>,
Brian <co...@mailvault.com> writes
>On Nov 17, 3:16 am, James Kanze <james.ka...@gmail.com> wrote:
>> On Nov 17, 7:08 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>
>> > krel wrote:
>> > > I've seen it mentioned in several places that some code
>> > > bases - open source projects or proprietary company code -
>> > > deliberately choose not use exceptions in their C++ code.
>> > > The only example I can come up with at the moment is are the
>> > > Google C++ guidelines however, I've seen that notions
>> > > expressed in various places.
>> > > What are some reason that a project would choose not to use
>> > > C++ exceptions?
>> > Lack off, or poor compiler support.
>>
>> Today? Except possibly for very small embedded systems. Fear,
>> uncertainy and doubt about compiler support, maybe, but
>> exceptions are probably more stable than templates or RTTI
>> today.
>>
>> Interoperatability with C would seem to me to be a more
>> significant reason. If an entire project is written in C++, I
>> don't see any real problem, but if you have C++ functions called
>> from C, and vice versa, you might want to pay attention.
>>
>
>I'm not sure why you say "vice versa." If you have C functions
>called from C++, what's the problem? You just check the return
>code and throw or proceed.
He says "_and_ vice versa."
If C++ function g() is called from C function f() which is called from
C++ main(), what happens if g() throws an exception?
--
Richard Herring
Brian
> In message
> <6168959f-a70f-47e9-be39-038b46199...@s31g2000yqs.googlegroups.com>,
> Brian <c...@mailvault.com> writes
Whoever wrote f() should be fired.
Brian Wood
http://webEbenezer.net
Paavo Helde
b526-364...@s31g2000yqs.googlegroups.com:
> On Nov 17, 8:43 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>> krel <k...@example.invalid> wrote innews:hduq8e$4f9$1...@news.eternal-
>> september.org:
and badly designed feature".
>
>> In C++, there are surprisingly few "broken and badly designed
>> features".
>
> That's very arguable. The question isn't so much whether C++
> does it right; it's usually a question of other languages not
> supporting it at all.
>
>> Non-empty exception specifications are one example,
>
> Broken and badly designed, or simply a more or less good
> solution without a problem?
I would say broken and badly designed as they solve even the perceived
problem inadequately (app termination is not an adequate solution imo,
and catch(...) is better than using a global unexpected handler).
I think the problem of having unexpected exceptions is real, but there is
already a better solution (catch(...)).
>
>> the "most-vexing-c++- parse" another. The latter was kept for
>> C compatibility, but I strongly suspect the amount of C code
>> saved this way is very close to zero.
>
> Are you kidding? Take a look at any of the C headers on your
> machine. How many systematically use "extern" before function
> declarations, and how many just count on the fact that a
> function declaration is always "extern", unless specified
> otherwise.
Hmm, I was thinking of a line like
S s(S());
where the inner S() is interpreted as a "function returning S taking no
arguments" (quotes from
http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/565098173
5).
Instead, this could be written in a more or less equivalent, yet less
ambiguous way as:
S s(S(*)());
or more clearly, using typedefs.
What I doubted was that there are any real-world headers containing
function declarations like
A x(B(), C(), D());
If this syntax were changed to mean object definition instead, the whole
class of user errors could be eliminated - or am I seriously mistaken
here?
Paavo
dragan
Because:
1. The "exception goto" creates spaghetti code.
2. Developers use them as a crutch instead of solving problems.
3. They don't understand them.
4. It would be easier to build a space shuttle.
5. They are not necessary.
6. They use other techniques.
7. They can't afford a C++ guru consultant.
8. They constrain the system design.
9. Google said they were bad.
10. All of the above.
11. Some of the above.
12. Other reason.
;)
dragan
Maybe it should and maybe constructors should be able to call other
constructors. So that one that you picked is probably not that bad. If that
is the case, exceptions don't look as useful. Maybe C++ is suitable ONLY for
large scale development? The exception (no pun) imposing on the common case
again?
dragan
> That's a good point. Exceptions when code isn't exception safe
> are a sure recepe for disaster, and code written before
> exception safety was known or understood generally won't be
> exception safe.
How long is the book on writing exception safe code? Or, how many books are
there? Or, is there a web page that sums it up quite nicely? Is it just a
few rules of thumb?
dragan
> In C++, there are surprisingly few "broken and badly designed
> features".
Opinions vary. The guy who wrote the recent post "Article on possible
improvements to C++" disagrees with your statement.
White Wolf
> krel wrote:
>> I've seen it mentioned in several places that some code bases - open
>> source projects or proprietary company code - deliberately choose not
>> use exceptions in their C++ code. The only example I can come up with
>> at the moment is are the Google C++ guidelines however, I've seen that
>> notions expressed in various places.
>>
>> What are some reason that a project would choose not to use C++
>> exceptions?
>
> Because:
>
> 1. The "exception goto" creates spaghetti code.
It is not a goto. It does not specify where it goes. It reports an
error detected by the thrower to the handler declared by the catch
statement.
> 2. Developers use them as a crutch instead of solving problems.
A sweeping generalization.
> 3. They don't understand them.
A sweeping generalization.
> 4. It would be easier to build a space shuttle.
False statement.
> 5. They are not necessary.
False statement. Any constructor that may fail and nearly any use of
the standard library will require exceptions.
> 6. They use other techniques.
There are no other techniques for the above mentioned 2 cases.
> 7. They can't afford a C++ guru consultant.
They don't need to. All they need to be able to afford is a copy of
Effective C++ 3rd edition.
> 8. They constrain the system design.
Yeah, they constrain it. That was the statement, i cannot se how it can
also be the reason. :)
> 9. Google said they were bad.
I doubt it. Google is represented (today I think) by 3 people at the
C++ standardization committee. IIRC all of them has participated in
designing and voting on the exception features for the first standard.
> 10. All of the above.
> 11. Some of the above.
> 12. Other reason.
I vote for this one. Ignorance and prejudice comes into my mind...
--
BR, WW
White Wolf
And he has demonstrated an unprecedented number of misconceptions and
very little knowledge of what he is talking about.
--
BR, WW
White Wolf
Effective C++ 3rd edition, very few items are about exceptions and there
is all you need to know.
--
BR, WW
dragan
> On Tue, 2009-11-17, Paavo Helde wrote:
> ...
>> Regarding Google, maybe they might have banned exceptions because of
>> the run-time overhead (just guessing). Throwing exceptions is
>> notoriously slow,
So what? Code outside of the mainline during exceptional conditions does not
have to be fast.
dragan
> dragan wrote:
>> Paavo Helde wrote:
>>
>>> In C++, there are surprisingly few "broken and badly designed
>>> features".
>>
>> Opinions vary. The guy who wrote the recent post "Article on possible
>> improvements to C++" disagrees with your statement.
>
> And he has demonstrated an unprecedented number of misconceptions
Unprecendented eh?
> and
> very little knowledge of what he is talking about.
He seems to know MUCH about low level implementation details. So if he knows
"very little", I must know only VERY VERY little. :(
(P.S. You missed the most important part of my other post that you "tore
up").
White Wolf
> Regarding Google, maybe they might have banned exceptions because of the
> run-time overhead (just guessing). Throwing exceptions is notoriously
> slow, so they should not be used unless something goes very wrong - but
> for a 24/7 service like Google nothing should go wrong ever, so no need
> for exceptions, right?
Notoriously slow is a pretty vague statement. Exceptions do not slower
the speed of the code unless they are thrown. So your choices are: slow
your happy code (that runs a billion times) by inserting hundreds of if
statements into it to propagate return codes up the call stack to the
handler, or make returning 1000 times slower 3 times a day... It is a
no brainer to me.
But in case of Google, there may be another reason. Exceptions are not
for reporting results of operations, they are to report errors that
cannot be handled where they are detected. Since Google services live
in a cloud, it may be easier to kill the misbehaving program (that could
not open a file) and restart the whole machine then trying to handle the
error. There will be a few million more computer who can do the thing.
So the real reason could be that Google has a lot easier way to deal
with misbehavior that normally would be handled by an exception. Move
the task to another process, machine, city... and kill the one that went
bananas.
But, this is still just a guess. :)
--
BR, WW
dragan
> Paavo Helde wrote:
>> Regarding Google, maybe they might have banned exceptions because of
>> the run-time overhead (just guessing). Throwing exceptions is
>> notoriously slow, so they should not be used unless something goes
>> very wrong - but for a 24/7 service like Google nothing should go
>> wrong ever, so no need for exceptions, right?
>
> Notoriously slow is a pretty vague statement. Exceptions do not
> slower the speed of the code unless they are thrown. So your choices
> are: slow your happy code (that runs a billion times) by inserting
> hundreds of if statements into it to propagate return codes up the
> call stack to the handler, or make returning 1000 times slower 3
> times a day... It is a no brainer to me.
You are arguing "either or", "one extreme or the other". :P
White Wolf
> White Wolf wrote:
>> dragan wrote:
>>> Paavo Helde wrote:
>>>
>>>> In C++, there are surprisingly few "broken and badly designed
>>>> features".
>>> Opinions vary. The guy who wrote the recent post "Article on possible
>>> improvements to C++" disagrees with your statement.
>> And he has demonstrated an unprecedented number of misconceptions
>
> Unprecendented eh?
No need for attitude. Yes. Unprecedented amounts of false assumptions.
>> and
>> very little knowledge of what he is talking about.
>
> He seems to know MUCH about low level implementation details. So if he knows
> "very little", I must know only VERY VERY little. :(
He seems. He write about his assumptions and misconceptions as if they
were fact. Very confident. very misleading. And yet, when you take a
closer look, you see that he does not even know what a compile time
constant is, and that upcasting+member access in multiple inheritance is
practically the same speed as in single inheritance.
He has a lot of wild guesses and presents them as fact.
I have found no evidence that he *knows* much about any low level
details. I have seen he has *opinions* about them, and presents them as
facts.
I probably shall have have no comments on your assessment of your own
knowledge of what you call low level details, but if you buy into the
wild guesses in that article without feeling uneasy, well, you are
probably right.
> (P.S. You missed the most important part of my other post that you "tore
> up").
I did not tear up anything. I have follow the USENET netiquette and
reply to those parts where I have something to say. And I am sorry, I
cannot identify what is "my other post". If you want to talk about that
other post, please reply to the other reply. :) Then I will have a
chance to understand why do you feel that I was unfair.
--
BR, WW
dragan
> dragan wrote:
>> White Wolf wrote:
>>> dragan wrote:
>>>> Paavo Helde wrote:
>>>>
>>>>> In C++, there are surprisingly few "broken and badly designed
>>>>> features".
>>>> Opinions vary. The guy who wrote the recent post "Article on
>>>> possible improvements to C++" disagrees with your statement.
>>> And he has demonstrated an unprecedented number of misconceptions
>>
>> Unprecendented eh?
>
> No need for attitude.
Ah, trying to turn the table huh. Well, you're well on your way to 5th grade
level of discussion.
>Yes. Unprecedented amounts of false
> assumptions.
You were exploiting and sensationalizing and you know it. Being caught in
the act, you try to play it down with the "try to turn the table" tactic.
What the child does not know is that the tactics are common knowledge. So
the child keeps believing that he/she is smarter than everyone else when in
reality the child is unknowingly showing his/her ignorance.
>
>>> and
>>> very little knowledge of what he is talking about.
>>
>> He seems to know MUCH about low level implementation details. So if
>> he knows "very little", I must know only VERY VERY little. :(
>
> He seems. He write about his assumptions and misconceptions as if
> they were fact.
And you write: "Unprecendented amounts of false assumptions", as if it were
fact. To which I replied: "Unprecedented eh?".
> Very confident. very misleading.
And you skip to literary correction when "new operator" was used even though
from the context it is clear what was being discussed. So, not only no bonus
for you, but penalty. :P
> And yet, when you
> take a closer look, you see that he does not even know what a compile
> time constant is, and that upcasting+member access in multiple
> inheritance is practically the same speed as in single inheritance.
>
> He has a lot of wild guesses and presents them as fact.
>
> I have found no evidence that he *knows* much about any low level
> details. I have seen he has *opinions* about them, and presents them
> as facts.
And you don't know that quotation marks are to be used where you used
asterisks above or maybe you are conveniently ignoring what quotation marks
do within a context to the meaning of the quoted words so that you can go on
with your childish tactics.
>
> I probably shall have have no comments on your assessment of your own
> knowledge of what you call low level details, but if you buy into the
> wild guesses in that article without feeling uneasy, well, you are
> probably right.
>
>> (P.S. You missed the most important part of my other post that you
>> "tore up").
>
> I did not tear up anything.
Oh no, of course not. (He he).
> I have follow the USENET netiquette and
> reply to those parts where I have something to say. And I am sorry, I
> cannot identify what is "my other post". If you want to talk about
> that other post, please reply to the other reply. :) Then I will
> have a chance to understand why do you feel that I was unfair.
I didn't say you were "unfair". The post you "tore up" is the one where I
had a list of 12 things. You missed the most important part. I hope you are
either 9 years old or have a wife, because you need help. :/
White Wolf
> White Wolf wrote:
>> I have found no evidence that he *knows* much about any low level
>> details. I have seen he has *opinions* about them, and presents them
>> as facts.
>
> And you don't know that quotation marks are to be used where you used
> asterisks above or maybe you are conveniently ignoring what quotation marks
> do within a context to the meaning of the quoted words so that you can go on
> with your childish tactics.
http://usenet4all.se/rfc1855.txt
"
- Use symbols for emphasis. That *is* what I meant. Use
underscores for underlining. _War and Peace_ is my favorite
book.
"
--
BR, WW
dragan
Oh, I gave you too much credit on that one then: I thought you were trying
to do something more than just emphasize those words. Nevermind on that one.
James Kanze
> James Kanze <james.ka...@gmail.com> wrote in
> news:f37f1e13-cdcc-4144-
> b526-364f2bcf6...@s31g2000yqs.googlegroups.com:
> > On Nov 17, 8:43 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
> >> krel <k...@example.invalid> wrote innews:hduq8e$4f9$1...@news.eternal-
> >> september.org:
> and badly designed feature".
> >> In C++, there are surprisingly few "broken and badly
> >> designed features".
> > That's very arguable. The question isn't so much whether
> > C++ does it right; it's usually a question of other
> > languages not supporting it at all.
> >> Non-empty exception specifications are one example,
> > Broken and badly designed, or simply a more or less good
> > solution without a problem?
> I would say broken and badly designed as they solve even the
> perceived problem inadequately (app termination is not an
> adequate solution imo, and catch(...) is better than using a
> global unexpected handler).
What is the perceived problem? And why is aborting (as a
default behavior) a bad solution? Violating an exception
specification is a contract violation, so aborting *is* about
the only appropriate default behavior. The question is: what
problem is solved by supporting contracts in which a function
is allowed to throw a limited set of exceptions (as opposed to
no exception).
> I think the problem of having unexpected exceptions is real,
> but there is already a better solution (catch(...)).
They don't detect the error when it occurs. And they result in
stack unwinding occurring---something you definitely don't want
if the exception is a contract violation.
> >> the "most-vexing-c++- parse" another. The latter was kept
> >> for C compatibility, but I strongly suspect the amount of C
> >> code saved this way is very close to zero.
> > Are you kidding? Take a look at any of the C headers on
> > your machine. How many systematically use "extern" before
> > function declarations, and how many just count on the fact
> > that a function declaration is always "extern", unless
> > specified otherwise.
> Hmm, I was thinking of a line like
> S s(S());
> where the inner S() is interpreted as a "function returning S
> taking no arguments" (quotes
> fromhttp://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/56509...
> 5).
> Instead, this could be written in a more or less equivalent,
> yet less ambiguous way as:
> S s(S(*)());
> or more clearly, using typedefs.
This example, yes. Changing it, however, would involve breaking
C compatibility. I was thinking of the common case:
S s(S(a));
, where a is an already existing variable. Regretfully, most
headers are full of this sort of thing, rather than e.g.:
extern S s(S(a));
(if they are declaring a function).
Again, in this simple case, you could drop the extra parentheses
in the function decaration, but banning an extra set of
encapsulating parentheses would complicate the grammar
excessively.
> What I doubted was that there are any real-world headers
> containing function declarations like
> A x(B(), C(), D());
> If this syntax were changed to mean object definition instead,
> the whole class of user errors could be eliminated - or am I
> seriously mistaken here?
Thinking about it: one could probably get away with 1) dropping
the implicit conversion of the parameter type for functions, and
2) banning outermost parentheses. It's an idea, but you'd need
some volenteer to come up with the wording for point 2, since it
means redefining the grammar for type expressions in some way.
--
James Kanze
James Kanze
> dragan wrote:
> > White Wolf wrote:
> >> dragan wrote:
> >>> Paavo Helde wrote:
> >>>> In C++, there are surprisingly few "broken and badly
> >>>> designed features".
> >>> Opinions vary. The guy who wrote the recent post "Article
> >>> on possible improvements to C++" disagrees with your
> >>> statement.
> >> And he has demonstrated an unprecedented number of misconceptions
> > Unprecendented eh?
> No need for attitude. Yes. Unprecedented amounts of false
> assumptions.
Just a linguistic nit, but formally, "unprecedented" means that
there is no precedent---no one has done it before. Given this
definition, I wouldn't call posting a web page on a subject you
know nothing about exactly "unprecedented":-).
Not that that that changes anything with regards to your
argument.
--
James Kanze
White Wolf
I was referring to an "unprecedented amount". I mean if we disregard
the known trolls. I do not regard the OP as a troll, so it made me very
sad to see so many bad assumptions.
--
BR, WW
dragan
> On Nov 21, 2:57 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>> James Kanze <james.ka...@gmail.com> wrote in
>> news:f37f1e13-cdcc-4144-
>> b526-364f2bcf6...@s31g2000yqs.googlegroups.com:
>
>>> On Nov 17, 8:43 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>>>> krel <k...@example.invalid> wrote innews:hduq8e$4f9$1...@news.eternal-
>>>> september.org:
>
>> and badly designed feature".
>
>>>> In C++, there are surprisingly few "broken and badly
>>>> designed features".
>
>>> That's very arguable. The question isn't so much whether
>>> C++ does it right; it's usually a question of other
>>> languages not supporting it at all.
>
>>>> Non-empty exception specifications are one example,
>
>>> Broken and badly designed, or simply a more or less good
>>> solution without a problem?
>
>> I would say broken and badly designed as they solve even the
>> perceived problem inadequately (app termination is not an
>> adequate solution imo, and catch(...) is better than using a
>> global unexpected handler).
>
> What is the perceived problem? And why is aborting (as a
> default behavior) a bad solution?
I've watched these threads before and found that they go around and around.
The reason is because you all are jumping the gun seeking the "one and only"
thing instead of being patient and doing some research. Error handling is
application-specific. Without a well-defined problem, discussions get no
where toward solution and no one learns anything. James, you said, "aborting
is not necessarily bad". Well, of course not. It depends on the application.
It is but one of many avenues to take upon detecting (detection is a key
concept) that a potentially "disastrous" thing will occur unless processing
doesn't take a side road immediately. If you believe what I just said, and I
believe you do, then you see why I question those who consider C++
exceptions as an error management strategy. C++ exceptions are JUST a
mechanism. NOT a solution to the error management problem. Yet I am sure
that chatter and banter about the mechanisms rather than the problem will
continue. How to accellerate the learning is the question.
> Violating an exception
> specification is a contract violation, so aborting *is* about
> the only appropriate default behavior.
Maybe. (Read, I'm not sure 'bout that). I don't know what you mean. Did you
just elevate "function argument requirements" to "exception specification"?
If so, given the current "climate" and confusion with error handling, you'd
expect me to BELIEVE your "exception specification" as some kind of
authoritative thing? C'mon, let's get real. "Before", there was "a function
has, "a contract". Are you suggesting now that a function has "an exception
specification" all is good? C'mon, who uses those things in C++? That is so
yesterday. It failed. Didn't it?
> The question is: what
> problem is solved by supporting contracts in which a function
> is allowed to throw a limited set of exceptions (as opposed to
> no exception).
No doubt you seek to write meaningless definitions for specifications? ;P
<-(combinatorial emoticon) (Should I patent it?).
>
>> I think the problem of having unexpected exceptions is real,
Define "unexpected exception" please. I didn't know that C++ recognized such
a beast. I can't quote anything from the standard or the tomes, but in my
mind remains that exceptions in C++ are EXPECTED things. Am I wrong or are
you? One of us has to be.
>> but there is already a better solution (catch(...)).
>
> They don't detect the error when it occurs.
To be real, detection is all about preventing "undefined behaviour". "error"
is not pondered about enough. Then again, I've never been taught programming
other than Jr. College where it was Pascal I think and everyone had to do it
(that's not important), so I don't know who failed the test in the course
and who didn't because I don't know what they/you are teaching.
> And they result in
> stack unwinding occurring---something you definitely don't want
> if the exception is a contract violation.
Did you just say, "C++ exceptions used as a crutch to understanding the
problem"?
dragan
> On Nov 21, 5:18 am, White Wolf <wo...@freemail.hu> wrote:
>> dragan wrote:
>>> White Wolf wrote:
>>>> dragan wrote:
>>>>> Paavo Helde wrote:
>
>>>>>> In C++, there are surprisingly few "broken and badly
>>>>>> designed features".
>>>>> Opinions vary. The guy who wrote the recent post "Article
>>>>> on possible improvements to C++" disagrees with your
>>>>> statement.
>>>> And he has demonstrated an unprecedented number of misconceptions
>
>>> Unprecendented eh?
>
>> No need for attitude. Yes. Unprecedented amounts of false
>> assumptions.
>
> Just a linguistic nit, but formally, "unprecedented" means that
> there is no precedent---no one has done it before.
Thank you James for spelling it out explicitly to Mr. Child.
> Given this
> definition, I wouldn't call posting a web page on a subject you
> know nothing about exactly "unprecedented":-).
"Duh".
>
> Not that that that changes anything with regards to your
> argument.
It does indeed if by "argument" you mean the little child suggesting that
_I_ have "an attitude".
dragan
While my method with you seems to have "subdued" you, my intention was only
show you what a baby you are. I think you may be a ticking time bomb. Get
some help. None of this shit is important.
James Kanze
Even within a single application, different types of errors will
require different types of handling. For that matter, the same
type of error may require different handling in different
contexts: a write error in a log file should probably be
ignored; a write error in the program output (e.g. when writing
the object file in a compiler) should probably result in the
program terminating with an error status (after clean-up---I
can't think of any case where a write error should result in an
abort).
> Without a well-defined problem, discussions get no where
> toward solution and no one learns anything. James, you said,
> "aborting is not necessarily bad". Well, of course not. It
> depends on the application.
Which is what I said. Most of the time, aborting is the
appropriate reaction, and it is the obvious choice for a default
action, but I'm well aware that there are exceptions: game
programs, for example, and possibly light weight GUI client
code.
> It is but one of many avenues to take upon detecting
> (detection is a key concept) that a potentially "disastrous"
> thing will occur unless processing doesn't take a side road
> immediately. If you believe what I just said, and I believe
> you do, then you see why I question those who consider C++
> exceptions as an error management strategy. C++ exceptions are
> JUST a mechanism. NOT a solution to the error management
> problem.
I don't think anyone has reasonably argued that exceptions are
an "error managment strategy". First, as you say, they are a
just a mechanism---a tool to implement a strategy, and not a
strategy. And second, they only address one aspect of error
management: reporting. Error management involves three aspects:
detection, reporting and handling. Exceptions don't help in
detection, nor in handling. They just simplify reporting when
the error must be handled far up the call stack. (Which means
that they are of no use when the error must be handled
immediately.)
> Yet I am sure that chatter and banter about the
> mechanisms rather than the problem will continue. How to
> accellerate the learning is the question.
> > Violating an exception specification is a contract
> > violation, so aborting *is* about the only appropriate
> > default behavior.
> Maybe. (Read, I'm not sure 'bout that). I don't know what you
> mean. Did you just elevate "function argument requirements" to
> "exception specification"?
I didn't elevate anything. I'm just describing what exception
specifications do.
> If so, given the current "climate" and confusion with error
> handling, you'd expect me to BELIEVE your "exception
> specification" as some kind of authoritative thing?
It is. Since the standard says it is. A function with an
exception specification "throw (std::bad_alloc)" may not exit by
any exception other than std::bad_alloc or an exception which
derives from std::bad_alloc. And the standard is authoritive.
Whether such a "contract" is practically useful is another
issue. In practice, the only contract expressible by exception
specifications which I've found useful is "throw()". In
otherwords, that the function will not exit by an exception,
period. Without it, you can't really write exception safe code.
> C'mon, let's get real. "Before", there was "a function has, "a
> contract". Are you suggesting now that a function has "an
> exception specification" all is good? C'mon, who uses those
> things in C++? That is so yesterday. It failed. Didn't it?
I'm having difficulty parsing what you're trying to say. But
programming by contract certainly hasn't failed, and is still
considered a good thing in most circles. As for exception
specifications, they're just another part of the contract. So
one can't say that they've failed. What one can say is that the
contract they express is not all that useful (with the exception
of an empty exception specification---a no-throw guarantee).
> > The question is: what problem is solved by supporting
> > contracts in which a function is allowed to throw a limited
> > set of exceptions (as opposed to no exception).
> No doubt you seek to write meaningless definitions for specifications? ;P
> <-(combinatorial emoticon) (Should I patent it?).
I didn't write the definition of exception specifications. It's
in the standard.
> >> I think the problem of having unexpected exceptions is
> >> real,
> Define "unexpected exception" please. I didn't know that C++
> recognized such a beast. I can't quote anything from the
> standard or the tomes, but in my mind remains that exceptions
> in C++ are EXPECTED things. Am I wrong or are you? One of us
> has to be.
I didn't write that, so I can't be sure, but a priori, an
"unexpected exception" is one that the programmer didn't expect;
that he wasn't prepared to handle.
> >> but there is already a better solution (catch(...)).
> > They don't detect the error when it occurs.
> To be real, detection is all about preventing "undefined
> behaviour". "error" is not pondered about enough. Then again,
> I've never been taught programming other than Jr. College
> where it was Pascal I think and everyone had to do it (that's
> not important), so I don't know who failed the test in the
> course and who didn't because I don't know what they/you are
> teaching.
> > And they result in stack unwinding occurring---something you
> > definitely don't want if the exception is a contract
> > violation.
> Did you just say, "C++ exceptions used as a crutch to
> understanding the problem"?
No. I never said that. I've always argued that exceptions are
a tool, to be used when appropriate, but that they don't solve
all problems. (Many years ago, I was rather down on exceptions,
because everyone was constantly saying that as soon as compilers
supported them, all problems concerning errors would disappear,
and no one was addressing the real problems concerning
additional paths in the program flow that they raise. Since
then, our understanding of the issues has evolved.)
--
James Kanze
James Kanze
> James Kanze wrote:
> > On Nov 21, 5:18 am, White Wolf <wo...@freemail.hu> wrote:
> >> dragan wrote:
> >>> White Wolf wrote:
> >>>> dragan wrote:
> >>>>> Paavo Helde wrote:
> >>>>>> In C++, there are surprisingly few "broken and badly
> >>>>>> designed features".
> >>>>> Opinions vary. The guy who wrote the recent post "Article
> >>>>> on possible improvements to C++" disagrees with your
> >>>>> statement.
> >>>> And he has demonstrated an unprecedented number of misconceptions
> >>> Unprecendented eh?
> >> No need for attitude. Yes. Unprecedented amounts of false
> >> assumptions.
> > Just a linguistic nit, but formally, "unprecedented" means
> > that there is no precedent---no one has done it before.
> Thank you James for spelling it out explicitly to Mr. Child.
I think you misunderstood my statement. I explicitly said "Just
a linguistic nit". All I disagreed with was his use of one
particular word. And that use, while not formally correct, is
quite idiomatic in English: you'll quite often hear "an
unprecedented amount of X" as an exagerated expression of "a lot
of X". I don't think any amount of misconceptions would be
"unprecedented", given the number of sites on the Web by authors
who clearly don't understand what they're talking about. But
the site in question clearly falls into the category of sites
pontificating on subjects which the authors don't know very
well, if at all.
--
James Kanze
James Kanze
> dragan wrote:
> > krel wrote:
> >> I've seen it mentioned in several places that some code
> >> bases - open source projects or proprietary company code -
> >> deliberately choose not use exceptions in their C++ code.
> >> The only example I can come up with at the moment is are
> >> the Google C++ guidelines however, I've seen that notions
> >> expressed in various places.
> >> What are some reason that a project would choose not to use
> >> C++ exceptions?
> > Because:
> > 1. The "exception goto" creates spaghetti code.
> It is not a goto. It does not specify where it goes. It
> reports an error detected by the thrower to the handler
> declared by the catch statement.
It is and it isn't. It is a goto, in the sense that it creates
additional possible program flow, which much must be taken into
account when analysing for correctness. It isn't, in the sense
that one of the major problems with goto is that it doesn't say
where we're coming from. Exceptions certainly don't have that
problem. And people like David Abrahams have successfully
addressed the issue of program flow, and least sufficiently for
exceptions to be acceptable in almost all code.
> > 2. Developers use them as a crutch instead of solving problems.
> A sweeping generalization.
A meaningless statement.
> > 3. They don't understand them.
> A sweeping generalization.
Probably true in the case of the poster, however.
> > 4. It would be easier to build a space shuttle.
> False statement.
Easier than what?
> > 5. They are not necessary.
> False statement. Any constructor that may fail and nearly any
> use of the standard library will require exceptions.
No. C++ without exceptions is still Turing complete, so they're
not absolutely necessary. On the other hand, most large,
complex applications will be more difficult to write correctly,
and require more resources to develop, if you don't use
exceptions.
> > 6. They use other techniques.
> There are no other techniques for the above mentioned 2 cases.
> > 7. They can't afford a C++ guru consultant.
> They don't need to. All they need to be able to afford is a
> copy of Effective C++ 3rd edition.
> > 8. They constrain the system design.
> Yeah, they constrain it. That was the statement, i cannot se
> how it can also be the reason. :)
> > 9. Google said they were bad.
> I doubt it. Google is represented (today I think) by 3 people
> at the C++ standardization committee. IIRC all of them has
> participated in designing and voting on the exception features
> for the first standard.
I haven't seen anywhere where Google has officially said
anything. And I don't think it would matter if they did---if
you look at the HTML emitted by Google mail, for example, you
know that quality is not an important issue for Google.
(IIRC, Google was not represented on the standards committee in
1998, when the first version of the standard was adopted. And
the text concerning exceptions was finalized before that. On
the other hand, at least one person currently representing
Google was a memer at the time, for a different company.)
--
James Kanze
White Wolf
I guess you have seen my other post where I spell out what I mean. It
does not create a new path. It creates automagically the same path that
you would need to create anyway - using ifs and returning error codes.
And it only goes backwards, unlike goto.
>>> 2. Developers use them as a crutch instead of solving problems.
>
>> A sweeping generalization.
>
> A meaningless statement.
I suppose it is, if the poster knows all C++ developers...
>>> 3. They don't understand them.
>
>> A sweeping generalization.
>
> Probably true in the case of the poster, however.
Yep, and perhaps a lot more people. But not all. :) And IMHO Scott
Meyers have managed to cover exceptions in surprisingly little space in
his 3rd edition. I do not state that exceptions are the cure for
everything, I do not even state that every program has to use them.
OTOH it is getting really tiresome how some think that exceptions are
the root of all evil, and they are demonizing a language features with
arguments that have been proven false over 10 years ago.
>>> 4. It would be easier to build a space shuttle.
>
>> False statement.
>
> Easier than what?
I guess easier than using exceptions... since that was the topic.
>>> 5. They are not necessary.
>
>> False statement. Any constructor that may fail and nearly any
>> use of the standard library will require exceptions.
>
> No. C++ without exceptions is still Turing complete, so they're
> not absolutely necessary. On the other hand, most large,
> complex applications will be more difficult to write correctly,
> and require more resources to develop, if you don't use
> exceptions.
That I call necessary. I mean of someone wants to stay in business..
>>> 9. Google said they were bad.
>
>> I doubt it. Google is represented (today I think) by 3 people
>> at the C++ standardization committee. IIRC all of them has
>> participated in designing and voting on the exception features
>> for the first standard.
>
> I haven't seen anywhere where Google has officially said
> anything. And I don't think it would matter if they did---if
> you look at the HTML emitted by Google mail, for example, you
> know that quality is not an important issue for Google.
>
> (IIRC, Google was not represented on the standards committee in
> 1998, when the first version of the standard was adopted. And
> the text concerning exceptions was finalized before that. On
> the other hand, at least one person currently representing
> Google was a memer at the time, for a different company.)
That is what I have said. AFAIK those people were already in the
committee. I did not mean Google itself. :-) Some was AT&T, some was
Sun Microsystems...
--
BR, WW
Krice
> 3. They don't understand them.
Would be great if someone could explain in simple way
what exception is. Why, how and when it should be used.
Richard
White Wolf <wo...@freemail.hu> spake the secret code
<4b0761d0$0$586$c5fe...@read01.usenet4all.se> thusly:
Agreed. I wrote a long review of that book here:
<http://legalizeadulthood.wordpress.com/2009/09/09/effective-c-3rd-edition-by-scott-meyers/>
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
io_x
"dragan" ha scritto nel messaggio news:3XINm.36496$Wd1....@newsfe15.iad...
> krel wrote:
>> What are some reason that a project would choose not to use C++
>> exceptions?
>
> Because:
>
> 1. The "exception goto" creates spaghetti code.
if this above is true it will be enought to not use exceptions
> 3. They don't understand them.
> 4. It would be easier to build a space shuttle.
> 5. They are not necessary.
> 6. They use other techniques.
> 7. They can't afford a C++ guru consultant.
> 8. They constrain the system design.
> 9. Google said they were bad.
> 10. All of the above.
> 11. Some of the above.
> 12. Other reason.
12. they not have "the written form"
"if(a/b > c) u=z;"
if "a/b" throw one exception
in the plain text above;
there is not a single char in
"if(a/b > c) u=z;"
that show this chanches
13. the "exception header" not "know" the point of code
where is the problem. Instead returning the error-result of the
function the program know where is the error
> ;)
James Kanze
> "dragan" ha scritto nel messaggionews:3XINm.36496$Wd1....@newsfe15.iad...
[...]
> 12. they not have "the written form"
> "if(a/b > c) u=z;"
> if "a/b" throw one exception
> in the plain text above;
> there is not a single char in
> "if(a/b > c) u=z;"
> that show this chanches
That's probably because there is no such chance:-).
But seriously, this is the one real problem with exceptions. And
the possibility of exceptions does require some additional
thought. But the problem has been addressed, and we do know
what has to be done.
> 13. the "exception header" not "know" the point of code
> where is the problem. Instead returning the error-result of the
> function the program know where is the error
That's the whole point of exceptions. They're for the sort of
problems where it doesn't matter where the problem occured; the
handling is the same. If you run out of memory processing a
request, for example, it doesn't matter where you were in the
processing when you ran out; you just abort the request (but not
the process) with an error message, and continue.
--
James Kanze
White Wolf
> On Nov 23, 8:09 pm, "io_x" <a...@b.c.invalid> wrote:
>> "dragan" ha scritto nel messaggionews:3XINm.36496$Wd1....@newsfe15.iad...
>
> [...]
>> 12. they not have "the written form"
>
>> "if(a/b > c) u=z;"
>
>> if "a/b" throw one exception
>> in the plain text above;
>> there is not a single char in
>> "if(a/b > c) u=z;"
>> that show this chanches
>
> That's probably because there is no such chance:-).
>
> But seriously, this is the one real problem with exceptions. And
> the possibility of exceptions does require some additional
> thought. But the problem has been addressed, and we do know
> what has to be done.
Yeah, exceptions are a bitch that way. They force us to think and write
correct programs. :)
(One time people started to show me examples of where exceptions would
cause trouble in code. For 95% of those examples I could recreate the
problem by having Jane Summer add an if and a return statement in the
middle of that (already too complex and badly designed) function... And
summer trainees do exist, and they do add return statements. :)
>> 13. the "exception header" not "know" the point of code
>> where is the problem. Instead returning the error-result of the
>> function the program know where is the error
>
> That's the whole point of exceptions. They're for the sort of
> problems where it doesn't matter where the problem occurred; the
> handling is the same. If you run out of memory processing a
> request, for example, it doesn't matter where you were in the
> processing when you ran out; you just abort the request (but not
> the process) with an error message, and continue.
One thing that confuses people is that they think that "handling" the
error means "fixing" the error, or "doing something and try again". It
may, but in most cases it won't be like that. Handling the error may
just mean what you have just said (even a bit less): stop doing what we
cannot do, meanwhile keep the system in a stable state, go on to some
task that we may be able to do.
Even sending an error message/log may be too much. Think of a system
that handles 400 SIP sessions per second as a border gateway. If
someone starts sending cr*p SIP messages and we end up logging the
details, our border gateway will create 400+ log entries per second. So
you should start bringing hard disks in wheel barrels to keep it running.
The job of a gateway is not to analyze or document, but to avert an
attack. We don't need to log anything. If the attack is ongoing, we
can analyze the packets of the failed sessions. If it stops, who cares.
(We will know there is an attack from the increased rejections and
perhaps the bandwidth.)
I guess that way of handling exceptions could be called "Nike from the
Opposite Universe": Just don't do it. ;)
--
BR, WW
James Kanze
> James Kanze wrote:
> > On Nov 23, 8:09 pm, "io_x" <a...@b.c.invalid> wrote:
> >> "dragan" ha scritto nel
> >> messaggionews:3XINm.36496$Wd1....@newsfe15.iad...
> > [...]
> > But seriously, this is the one real problem with exceptions.
> > And the possibility of exceptions does require some
> > additional thought. But the problem has been addressed, and
> > we do know what has to be done.
> Yeah, exceptions are a bitch that way. They force us to think
> and write correct programs. :)
They introduce hidden flow paths which have to be considered
when evaluating program correctness. The fact that they don't
appear in the source code does increase the chance that they are
overlooked, and the fact that a lot of functions aren't
guaranteed to be no throw, although in fact they are, and if
return codes were used, they would still return void, increases
the actual workload, since without the nothrow guarantee, you
have to consider that they might throw.
How much extra effort and risk this entails has to be weighed
against the extra effort and risk of not using exceptions. Most
of the time, exceptions win.
--
James Kanze
peter koch
> On Nov 24, 12:53 am, White Wolf <wo...@freemail.hu> wrote:
>
> > James Kanze wrote:
> > > On Nov 23, 8:09 pm, "io_x" <a...@b.c.invalid> wrote:
> > >> "dragan" ha scritto nel
> > >> messaggionews:3XINm.36496$Wd1....@newsfe15.iad...
> > > [...]
> > > But seriously, this is the one real problem with exceptions.
> > > And the possibility of exceptions does require some
> > > additional thought. But the problem has been addressed, and
> > > we do know what has to be done.
> > Yeah, exceptions are a bitch that way. They force us to think
> > and write correct programs. :)
>
> They introduce hidden flow paths which have to be considered
> when evaluating program correctness. The fact that they don't
> appear in the source code does increase the chance that they are
> overlooked, and the fact that a lot of functions aren't
> guaranteed to be no throw, although in fact they are, and if
> return codes were used, they would still return void, increases
> the actual workload, since without the nothrow guarantee, you
> have to consider that they might throw.
>
Yes, but 99% of the time what is required is that your classes have
the basic exception guarantee - that you use RAII. The last one
percent you have to do some manual roll-back, but that code would have
to exist also in code not using exceptions.
> How much extra effort and risk this entails has to be weighed
> against the extra effort and risk of not using exceptions. Most
> of the time, exceptions win.
When not using exceptions, you more or less write the hidden error-
returning path explicitly in your code. In my experience, this often
gives a signicifand increase in source-code size and also obscures the
algorithm. This is a source of bugs, and the effort required to
explicite the path is normally much larger than the effort used to
write exception safe code.
/Peter
Richard
peter koch <peter.ko...@gmail.com> spake the secret code
<cf6e1ba1-abc1-48ac...@m11g2000vbo.googlegroups.com> thusly:
>When not using exceptions, you more or less write the hidden error-
>returning path explicitly in your code. In my experience, this often
>gives a signicifand increase in source-code size and also obscures the
>algorithm. This is a source of bugs, and the effort required to
>explicite the path is normally much larger than the effort used to
>write exception safe code.
I agree with this -- manual error handling obscures the normal flow
of the code and makes it very hard to read, understand and debug.
James Kanze
Perhaps the biggest argument against exceptions is that naive
programmers think that using RAII is sufficient for making
everything exception-safe:-).
Seriously, there's more to it than that, but good transactional
semantics do go a long way. And transactional semantics are a
fairly well studied field; historically, it's not been usual to
apply them to analysing program correctness, but there's no
reason why it can't be done. It does increase the work
somewhat, but so does adding tons of additional if's to check
error conditions that you can't treat immediately either.
> > How much extra effort and risk this entails has to be
> > weighed against the extra effort and risk of not using
> > exceptions. Most of the time, exceptions win.
> When not using exceptions, you more or less write the hidden
> error-returning path explicitly in your code.
Exactly. Explicitly, so you see the paths, and don't forget to
analyse them for correctness as well.
> In my experience, this often gives a signicifand increase in
> source-code size and also obscures the algorithm.
And that's the down-side. It's a trade-off. If the error has
to be handled immediately anyway, there's not really any
additional code (an if on one hand, a try block on the other),
and the hidden paths cost more, so you use a return code. If
the error can't be handled until considerably further up the
call stack, adding if's in every intermediate function does have
significant cost, which usually outweighs the cost of having to
consider the hidden flow paths. At least if you can count on
no-throw guarantees for enough fundamental operations to ensure
transactional integrity.
> This is a source of bugs, and the effort required to explicite
> the path is normally much larger than the effort used to write
> exception safe code.
Only if the error handling code isn't in the function where you
would have to write the explicit if's.
--
James Kanze
dragan
But that was my point: "one and only" mechanism is the "looking for the
silver bullet" approach.
> For that matter, the same
> type of error may require different handling in different
> contexts: a write error in a log file should probably be
> ignored; a write error in the program output (e.g. when writing
> the object file in a compiler) should probably result in the
> program terminating with an error status (after clean-up---I
> can't think of any case where a write error should result in an
> abort).
>
>> Without a well-defined problem, discussions get no where
>> toward solution and no one learns anything. James, you said,
>> "aborting is not necessarily bad". Well, of course not. It
>> depends on the application.
>
> Which is what I said. Most of the time, aborting is the
> appropriate reaction,
Reaction to what is the question. You must have something(s) specific in
mind.
> and it is the obvious choice for a default
> action,
Along with logging, backtracing, notification, perhaps restarting from
checkpoint, maybe rollback, maybe switching to redundant system 3...
Application-specific. Perhaps the only place abort is appropriate is in
language newsgroups! ;)
> but I'm well aware that there are exceptions: game
> programs, for example, and possibly light weight GUI client
> code.
>
>> It is but one of many avenues to take upon detecting
>> (detection is a key concept) that a potentially "disastrous"
>> thing will occur unless processing doesn't take a side road
>> immediately. If you believe what I just said, and I believe
>> you do, then you see why I question those who consider C++
>> exceptions as an error management strategy. C++ exceptions are
>> JUST a mechanism. NOT a solution to the error management
>> problem.
>
> I don't think anyone has reasonably argued that exceptions are
> an "error managment strategy". First, as you say, they are a
> just a mechanism---a tool to implement a strategy, and not a
> strategy. And second, they only address one aspect of error
> management: reporting.
They don't do that at all. Exceptions are an error propogation mechanism in
C++, an probably best to use sparingly for places where local "handling" is
not possible (constructors, for one) or not appropriate (independently
developed libraries). Reporting comes after exceptions have done their part.
> Error management involves three aspects:
> detection, reporting and handling.
There is also: error definition & categorization and propogation. So I see
at least 5 things. If I ponder a bit more here, I may come up with a few
more things. I do know that I wouldn't call simply
detection/handling/reporting "error management" though, and that's not what
I meant when I used the terms. Documentation, communication and enforcement
of the prescribed or chosen strategies and patterns are a few more (see, I
came up with a few more in 1 minute). "Error management" as simply
detection/handling/reporting? Nah. No way.
> Exceptions don't help in
> detection, nor in handling. They just simplify reporting when
> the error must be handled far up the call stack.
That's propogation, not reporting.
> (Which means
> that they are of no use when the error must be handled
> immediately.)
Catch = handle error
>
>> Yet I am sure that chatter and banter about the
>> mechanisms rather than the problem will continue. How to
>> accellerate the learning is the question.
>
>>> Violating an exception specification is a contract
>>> violation, so aborting *is* about the only appropriate
>>> default behavior.
>
>> Maybe. (Read, I'm not sure 'bout that). I don't know what you
>> mean. Did you just elevate "function argument requirements" to
>> "exception specification"?
>
> I didn't elevate anything. I'm just describing what exception
> specifications do.
I thought they were just documentation like precondition documentation.
>
>> If so, given the current "climate" and confusion with error
>> handling, you'd expect me to BELIEVE your "exception
>> specification" as some kind of authoritative thing?
>
> It is. Since the standard says it is. A function with an
> exception specification "throw (std::bad_alloc)" may not exit by
> any exception other than std::bad_alloc or an exception which
> derives from std::bad_alloc. And the standard is authoritive.
>
> Whether such a "contract" is practically useful is another
> issue.
That's why I hinting it was not authoritive. Bad choice of word (even the
way I speeled it!)
> In practice, the only contract expressible by exception
> specifications which I've found useful is "throw()". In
> otherwords, that the function will not exit by an exception,
> period. Without it, you can't really write exception safe code.
>
>> C'mon, let's get real. "Before", there was "a function has, "a
>> contract". Are you suggesting now that a function has "an
>> exception specification" all is good? C'mon, who uses those
>> things in C++? That is so yesterday. It failed. Didn't it?
>
> I'm having difficulty parsing what you're trying to say. But
> programming by contract certainly hasn't failed, and is still
> considered a good thing in most circles. As for exception
> specifications, they're just another part of the contract. So
> one can't say that they've failed.
Do you always use exception specifications? Do you people who never use
them?
> What one can say is that the
> contract they express is not all that useful
That's what I was hinting at, but not that I'm a one to discuss such C++
advanced topic.
> (with the exception
> of an empty exception specification---a no-throw guarantee).
Now exception (error) guarantees I can relate to: weak, basic, strong,
no-throw.
>
>>> The question is: what problem is solved by supporting
>>> contracts in which a function is allowed to throw a limited
>>> set of exceptions (as opposed to no exception).
>
>> No doubt you seek to write meaningless definitions for
>> specifications? ;P <-(combinatorial emoticon) (Should I patent it?).
>
> I didn't write the definition of exception specifications. It's
> in the standard.
I was suggesting that you were maybe pontificating on purpose more far than
necessary from the practical.
>
>>>> I think the problem of having unexpected exceptions is
>>>> real,
>
>> Define "unexpected exception" please. I didn't know that C++
>> recognized such a beast. I can't quote anything from the
>> standard or the tomes, but in my mind remains that exceptions
>> in C++ are EXPECTED things. Am I wrong or are you? One of us
>> has to be.
>
> I didn't write that, so I can't be sure, but a priori, an
> "unexpected exception" is one that the programmer didn't expect;
> that he wasn't prepared to handle.
I was thinking more from the detection level rather than
the-user-of-a-library level. Even if he didn't actually handle it and
because C++ default-handle it, it becomes "expected". IOTW,
"expected/unexpected" is more for discussion of how the C++ exception
mechanisms were designed: no exception goes unhandled.
dragan
> On Nov 22, 6:27 am, "dragan" <spambus...@prodigy.net> wrote:
>> James Kanze wrote:
>>> On Nov 21, 5:18 am, White Wolf <wo...@freemail.hu> wrote:
>>>> dragan wrote:
>>>>> White Wolf wrote:
>>>>>> dragan wrote:
>>>>>>> Paavo Helde wrote:
>
>>>>>>>> In C++, there are surprisingly few "broken and badly
>>>>>>>> designed features".
>>>>>>> Opinions vary. The guy who wrote the recent post "Article
>>>>>>> on possible improvements to C++" disagrees with your
>>>>>>> statement.
>>>>>> And he has demonstrated an unprecedented number of misconceptions
>
>>>>> Unprecendented eh?
>
>>>> No need for attitude. Yes. Unprecedented amounts of false
>>>> assumptions.
>
>>> Just a linguistic nit, but formally, "unprecedented" means
>>> that there is no precedent---no one has done it before.
>
>> Thank you James for spelling it out explicitly to Mr. Child.
>
> I think you misunderstood my statement. I explicitly said "Just
> a linguistic nit". All I disagreed with was his use of one
> particular word.
Me too.
> And that use, while not formally correct, is
> quite idiomatic in English: you'll quite often hear "an
> unprecedented amount of X" as an exagerated expression of "a lot
> of X".
I was pointing that out because he was using it to bash the other guy for
doing something similar.
> I don't think any amount of misconceptions would be
> "unprecedented", given the number of sites on the Web by authors
> who clearly don't understand what they're talking about. But
> the site in question clearly falls into the category of sites
> pontificating on subjects which the authors don't know very
> well, if at all.
I thought some of the things were fine for a NEW language, but not for C++.
A lot of the material there is over my head though.
dragan
You seem to be big on aborting. A very valid pattern is fixing the problem
and resuming. Some version of Windows expands the stack that way: a
violation occurs when trying to push beyond the current stack frame and the
system catches the error, expands the stack by 4k and continues processing.
(Not to bring up "termination vs. resumption" semantics, but not trying to
curb such discussion either. I'll just lurk and learn something). :)
dragan
Unless you are Google!?
dragan
Can you give some numbers?
> and also obscures the
> algorithm.
I don't see why. Hide the details with macros.
> This is a source of bugs,
Yes, probably, without any formalism such as macros. I guess you could go a
step further and write a preprocessor do do some instrumentation for you
also.
> and the effort required to
> explicite the path is normally much larger than the effort used to
> write exception safe code.
I think that would be the same or maybe harder with exceptions because of
the interactions with other C++ stuff (not that I can name that other stuff
though). Ensuring cleanup and RAII and call order and the like is an
on-going thing no matter what your EH strategies are.
peter koch
> > against the extra effort and risk of not using exceptions.
> > Most of the time, exceptions win.
>
I believe what we are discussing now is "Google open source" not
Googles own software, which I don't know.
/Peter
peter koch
> peter koch wrote:
> > On 24 Nov., 10:48, James Kanze <james.ka...@gmail.com> wrote:
>
> > When not using exceptions, you more or less write the hidden error-
> > returning path explicitly in your code. In my experience, this often
> > gives a signicifand increase in source-code size
>
> Can you give some numbers?
Not any exact ones, but I have been working in places where exceptions
were not used (due to some code being quite old and no one caring
about fixing). Code there typically looked something like:
int func(parm p,std::string &result)
{
std::string s;
int error;
result = func_1(parm,s);
if (error != OK)
{
return error;
}
error = func_2(s);
if (error != OK)
{
return error;
}
result = s;
return OK;
}
instead of the much simpler
std::string func(parm)
{
return func_2(func_1(parm));
}
This example is a bit exaggerated, as the function body does not do
very much, but it not atypical. One side effect of this style was that
functions typically returned a status, making calling the functions
more complicated. My guess is that the code length was at least
doubled this way. The above function has a 10-fold increase in lines
(disregarding braces), and it is not that easy to figure out what is
going on.
>
> > and also obscures the
> > algorithm.
>
> I don't see why. Hide the details with macros.
First that would require you to use macroes, which can lead to more
errors. Secondly: How would you hide the details in the code above?
>
> > This is a source of bugs,
>
> Yes, probably, without any formalism such as macros. I guess you could go a
> step further and write a preprocessor do do some instrumentation for you
> also.
Yes. You could also use another language. If you get so far out that
you need to write a preprocessor that proposition might acutally be
worth following.
>
> > and the effort required to
> > explicite the path is normally much larger than the effort used to
> > write exception safe code.
>
> I think that would be the same or maybe harder with exceptions because of
> the interactions with other C++ stuff (not that I can name that other stuff
> though). Ensuring cleanup and RAII and call order and the like is an
> on-going thing no matter what your EH strategies are.
As you, I see no interaction with other C++ stuff. Exceptions fit
perfectly with C++.
/Peter
Stuart Golodetz
> On Nov 21, 2:57 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>> James Kanze <james.ka...@gmail.com> wrote in
>> news:f37f1e13-cdcc-4144-
>> b526-364f2bcf6...@s31g2000yqs.googlegroups.com:
>
>>> On Nov 17, 8:43 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
>>>> krel <k...@example.invalid> wrote innews:hduq8e$4f9$1...@news.eternal-
>>>> september.org:
>
>> and badly designed feature".
>
>>>> designed features".
>
>>> C++ does it right; it's usually a question of other
>>> languages not supporting it at all.
>
>>>> Non-empty exception specifications are one example,
>
>>> Broken and badly designed, or simply a more or less good
>>> solution without a problem?
>
>> I would say broken and badly designed as they solve even the
>> perceived problem inadequately (app termination is not an
>> adequate solution imo, and catch(...) is better than using a
>> global unexpected handler).
>
> What is the perceived problem? And why is aborting (as a
> specification is a contract violation, so aborting *is* about
> problem is solved by supporting contracts in which a function
> is allowed to throw a limited set of exceptions (as opposed to
> no exception).
I don't really understand why the violation check's being done at
runtime rather than compile time (the way checked exceptions in Java
work) - the "what should happen if an unexpected exception is thrown at
runtime?" question is fair enough, but why does it get to that point in
the first place? Is it difficult/impossible to do the check at compile
time in C++? Or is the issue that it would break a lot of old code where
the functions don't have exception specifications?
Stu
Alf P. Steinbach
>
> Not any exact ones, but I have been working in places where exceptions
> were not used (due to some code being quite old and no one caring
> about fixing). Code there typically looked something like:
>
> int func(parm p,std::string &result)
> {
> std::string s;
> int error;
>
> result = func_1(parm,s);
> if (error != OK)
> {
> return error;
> }
> error = func_2(s);
> if (error != OK)
> {
> return error;
> }
> result = s;
> return OK;
> }
>
> instead of the much simpler
>
> std::string func(parm)
> {
> return func_2(func_1(parm));
> }
He he :-)
Thank you.
I don't think I've ever seen a more clear example.
Cheers,
- Alf
PS: Btw., the shop should have used s.swap( result ). ;-)
Richard
peter koch <peter.ko...@gmail.com> spake the secret code
<99e979fd-651c-4a27...@e27g2000yqd.googlegroups.com> thusly:
>int func(parm p,std::string &result)
>{
> std::string s;
> int error;
>
> result = func_1(parm,s);
> if (error != OK)
> {
> return error;
> }
> error = func_2(s);
> if (error != OK)
> {
> return error;
> }
> result = s;
> return OK;
>}
>
>instead of the much simpler
>
>std::string func(parm)
>{
> return func_2(func_1(parm));
>}
This sort of code is profusely present in code that uses COM because
every method on a COM interface typically returns an HRESULT status
code that you should check.
There are three ways I've seen people deal with such error codes:
- ignore them and pretend errors never happen (bad code)
- inline handling as above (hard to read code)
- map HRESULTs to exceptions and handle them at the appropriate
boundaries (throwing a C++ exception is undefined when implementing
a COM object, so you have to catch and bubble out HRESULTs)
The latter is the approach I have been teaching for almost 10+ years
now and it dramatically simplifies writing and understanding such
code.
James Kanze
So we agree. (On that, at least.)
> > For that matter, the same type of error may require
> > different handling in different contexts: a write error in a
> > log file should probably be ignored; a write error in the
> > program output (e.g. when writing the object file in a
> > compiler) should probably result in the program terminating
> > with an error status (after clean-up---I can't think of any
> > case where a write error should result in an abort).
> >> Without a well-defined problem, discussions get no where
> >> toward solution and no one learns anything. James, you
> >> said, "aborting is not necessarily bad". Well, of course
> >> not. It depends on the application.
> > Which is what I said. Most of the time, aborting is the
> > appropriate reaction,
> Reaction to what is the question. You must have something(s)
> specific in mind.
When you detect a coding error (a violation of a precondition,
for example), aborting is *usually* the most appropriate
reaction. Not aborting should only be done in explicit cases,
where you understand the issues and are prepared to cope with
them.
> > and it is the obvious choice for a default action,
> Along with logging, backtracing, notification, perhaps
> restarting from checkpoint, maybe rollback, maybe switching to
> redundant system 3... Application-specific. Perhaps the only
> place abort is appropriate is in language newsgroups! ;)
Abort is generally the most effective means fo switching to the
backup system. It's the generally accepted means of reacting to
software errors. More generally, if a program is doing the
wrong thing, it generally should be stopped as quickly as
possible, so that it doesn't do more of the wrong thing.
> > but I'm well aware that there are exceptions: game programs,
> > for example, and possibly light weight GUI client code.
> >> It is but one of many avenues to take upon detecting
> >> (detection is a key concept) that a potentially
> >> "disastrous" thing will occur unless processing doesn't
> >> take a side road immediately. If you believe what I just
> >> said, and I believe you do, then you see why I question
> >> those who consider C++ exceptions as an error management
> >> strategy. C++ exceptions are JUST a mechanism. NOT a
> >> solution to the error management problem.
> > I don't think anyone has reasonably argued that exceptions
> > are an "error managment strategy". First, as you say, they
> > are a just a mechanism---a tool to implement a strategy, and
> > not a strategy. And second, they only address one aspect of
> > error management: reporting.
> They don't do that at all. Exceptions are an error propogation
> mechanism in C++,
Error propagation, error reporting: same thing, really.
Propagation is probably the better word, though; it just slipped
my mind.
> an probably best to use sparingly for places where local
> "handling" is not possible (constructors, for one) or not
> appropriate (independently developed libraries).
Exactly.
> Reporting comes after exceptions have done their part.
I think we're talking about different things. I was talking
about "reporting" the error to the location in the code where it
would be handled.
> > Error management involves three aspects:
> > detection, reporting and handling.
> There is also: error definition & categorization and propogation.
Propagation is reporting, at least in the sense I was using the
word. Categorization is probably part of detection.
> So I see at least 5 things. If I ponder a bit more here, I may
> come up with a few more things.
You can certainly define it a lot finer, and there's often a lot
in each of those words. My basic idea was that you have to
think of errors in three contexts: where you're going to detect
the error (e.g. how, what type of error, etc.), where you're
going to treat it (log it, retry, etc.), and in between, where
you have to propagate it from where it was detected to where it
is to be handled.
> I do know that I wouldn't call simply
> detection/handling/reporting "error management" though, and
> that's not what I meant when I used the terms. Documentation,
> communication and enforcement of the prescribed or chosen
> strategies and patterns are a few more (see, I came up with a
> few more in 1 minute). "Error management" as simply
> detection/handling/reporting? Nah. No way.
At the coding level:-). I totally agree, my categorization
doesn't cover things like documentation and communication (to
other programmers), and they are very important.
> > Exceptions don't help in detection, nor in handling. They
> > just simplify reporting when the error must be handled far
> > up the call stack.
> That's propogation, not reporting.
Two words, same thing.
> > (Which means that they are of no use when the error must be
> > handled immediately.)
> Catch = handle error
Yes, but having to write a try block, then a catch statement, is
more complicated than an if, if you want to process the error
immediately. You can use an exception, but it's about like
pealing a grape with a butcher's cleaver.
--
James Kanze
Alf P. Steinbach
>
> Yes, but having to write a try block, then a catch statement, is
> more complicated than an if, if you want to process the error
> immediately. You can use an exception, but it's about like
> pealing a grape with a butcher's cleaver.
Off the cuff,
#define CATCHX( result, f, args ) \
do { \
try { \
result = f args; \
} catch( std::exception const& x ) { \
result.set_x( x ); \
} \
} while( false )
Cheers & hth.,
- Alf
James Kanze
> <snip>
There are (I think) several reasons. One obvious one is that
that if you don't specify anything, the compiler will assume
that a function can throw anything, so you'd end up needing a
lot of otherwise useless try blocks with legacy code (since the
code doesn't declare that it can't throw, but it doesn't in fact
ever throw, and you know that). The other is the IMHO misguided
theory that it would require the programmer to provide
additional runtime checks. If, for example, you have a sqrt
function with throws if passed a negative value, and you write
something like:
double
checked_sqrt(double in) throw()
{
return in < 0.0 ? 0.0 : sqrt(in);
}
you'd need a try block to tell the compiler that you're not
going to allow any exceptions to escape. (As I said, I don't
actually agree with this reasoning. But it's a reason I've
heard cited.)
--
James Kanze
James Kanze
> >> "if(a/b > c) u=z;"
Attention about word use. There's aborting (in the sense of
calling abort()), and aborting (in the more general sense, of
immediately terminating some action that you were in the process
of doing). In this case, I'm using the other sense: say you've
received a request on your LDAP server, and you run out of
memory trying to service it (because it requires interpreting
some obscenely complicated filter expression, for example).
When you detect the lack of memory, you're down in some really
deap parsing function, executing operator new. You (or rather
the system) raises an std::bad_alloc exception, which you catch
at the top level, and abort the request (not the program),
returning an error message of "insufficient resources", or the
like.
> A very valid pattern is fixing the problem and resuming.
If that's a valid reaction to the error, aborting isn't the
answer. If the error was a coding error, you can't fix the
source, recompile the code, and resume, so you abort. If the
error was insufficient memory due to an overly complicated
request, you can't simplify the request and resume: you abort
the operation. (On receiving an "insufficient resources" error,
of course, the client may try a simpler request.)
> Some version of Windows expands the stack that way: a
> violation occurs when trying to push beyond the current stack
> frame and the system catches the error, expands the stack by
> 4k and continues processing.
(Isn't that how most systems work? That's more or less the way
the old Berkley kernel worked on Sun 3's, and IIRC, PDP-11's
memory manager unit was designed expressedly to support
something like this, back in the days before virtual memory.)
I'm not too sure how that's relevant to user code, however. Are
you saying that if you get std::bad_alloc, you should try to get
more memory?
Frankly, out of memory is a special case, and most of the
programs I've worked on installed a new_handler to abort in such
cases. Not all, however, and particularly on transaction based
systems where transactions can require a lot of memory, it often
makes sense to just abort the transation. I can't think of much
else you could do: call some system routine to create more
virtual memory? That often requires priviledged access. And
if the insufficient memory was because you'd used up your
address space, rather than because the system didn't have any
more memory to give you, it won't help anyway. And you can do
it from the new_handler (which provides resumption semantics).
--
James Kanze
Stuart Golodetz
I guess you could always go down the Java-like route of introducing a
checked_exception base class for exceptions which can be checked in
exception specifications and assuming that where legacy code does throw,
it throws only unchecked exceptions. Not sure this would make things any
easier though?
>The other is the IMHO misguided
> theory that it would require the programmer to provide
> additional runtime checks. If, for example, you have a sqrt
> function with throws if passed a negative value, and you write
> something like:
>
> double
> checked_sqrt(double in) throw()
> {
> return in < 0.0 ? 0.0 : sqrt(in);
> }
>
> you'd need a try block to tell the compiler that you're not
> going to allow any exceptions to escape. (As I said, I don't
> actually agree with this reasoning. But it's a reason I've
> heard cited.)
Just to clarify: do you think it doesn't need a try block, or that
that's not a problem? (FWIW, my current answers to those would be that I
think it does need a try block, but that I don't think that's a major
problem - but I'm open to thoughts.)
Cheers,
Stu
> --
> James Kanze
Brian
>
> Attention about word use. There's aborting (in the sense of
> calling abort()), and aborting (in the more general sense, of
> immediately terminating some action that you were in the process
> of doing). In this case, I'm using the other sense: say you've
> received a request on your LDAP server, and you run out of
> memory trying to service it (because it requires interpreting
> some obscenely complicated filter expression, for example).
> When you detect the lack of memory, you're down in some really
> deap parsing function, executing operator new. You (or rather
> the system) raises an std::bad_alloc exception, which you catch
> at the top level, and abort the request (not the program),
> returning an error message of "insufficient resources", or the
> like.
Thanks for the clarification. I wasn't sure exactly what you
meant in prior posts and was thinking about asking.
>
> > A very valid pattern is fixing the problem and resuming.
>
> If that's a valid reaction to the error, aborting isn't the
> answer. If the error was a coding error, you can't fix the
> source, recompile the code, and resume, so you abort.
Agreed.
> If the
> error was insufficient memory due to an overly complicated
> request, you can't simplify the request and resume: you abort
> the operation. (On receiving an "insufficient resources" error,
> of course, the client may try a simpler request.)
Previously I've suggested adding a mechanism to the language
to support preventing an exception from causing base classes
from being destroyed if the exception occurs in, for example,
the most derived class. I thought about it in baseball terms
-- a single is often still useful even though not as good as
a double or more. In a marshalling context, a lot of work
has been done by another computer, the network and the
computer that is receiving the object. It makes sense to
me to have a way to preserve that work. (I'm not saying
that the default behaviour should be changed, but that a
way to get this behaviour should be added.) I also thought
of this in terms of a conversation between two people --
if you hear 90% of what someone tell you, you try to tell
them where you lost them and ask them to just repeat a
fraction of the original statement.
Brian Wood
http://webEbenezer.net
dragan
Completely different. Reporting = things like displaying an error dialogbox,
writing to an event log, sending a backtrace to the admin or developer...
Propogation is just that: propogating an error from the detection point to
the handling point. That may be as simple as returning an error code back up
the call stack or as not-simple as jumping to the handler with an error
object off some kind via an exception mechanism.
Reporting is a "handling" strategy. Propogation is more just about
mechanisms.
> Propagation is probably the better word, though; it just slipped
> my mind.
>
>> Reporting comes after exceptions have done their part.
>
> I think we're talking about different things. I was talking
> about "reporting" the error to the location in the code where it
> would be handled.
That isn't reporting. It's propogation. You are using terminology
incorrectly and that is sure to confuse.
>
>>> Error management involves three aspects:
>>> detection, reporting and handling.
>
>> There is also: error definition & categorization and propogation.
>
> Propagation is reporting, at least in the sense I was using the
> word.
That is incorrect.
> Categorization is probably part of detection.
No. Perhaps "classification" is a better word for clarification.
>
>> So I see at least 5 things. If I ponder a bit more here, I may
>> come up with a few more things.
>
> You can certainly define it a lot finer, and there's often a lot
> in each of those words.
It's not a question of more granularity. The issue at hand is recognizing
the larger scope of error management vs. just a subset of the technical
constituents of it.
> My basic idea was that you have to
> think of errors in three contexts: where you're going to detect
> the error (e.g. how, what type of error, etc.), where you're
> going to treat it (log it, retry, etc.), and in between, where
> you have to propagate it from where it was detected to where it
> is to be handled.
>
>> I do know that I wouldn't call simply
>> detection/handling/reporting "error management" though, and
>> that's not what I meant when I used the terms. Documentation,
>> communication and enforcement of the prescribed or chosen
>> strategies and patterns are a few more (see, I came up with a
>> few more in 1 minute). "Error management" as simply
>> detection/handling/reporting? Nah. No way.
>
> At the coding level:-).
Not even at the coding level. To say detect/handle/report is an error of
omission even at the coding level.
> I totally agree, my categorization
> doesn't cover things like documentation and communication (to
> other programmers), and they are very important.
>
>>> Exceptions don't help in detection, nor in handling. They
>>> just simplify reporting when the error must be handled far
>>> up the call stack.
>
>> That's propogation, not reporting.
>
> Two words, same thing.
Not the same at all. Orthogonal.
>
>>> (Which means that they are of no use when the error must be
>>> handled immediately.)
>
>> Catch = handle error
>
> Yes, but having to write a try block, then a catch statement, is
> more complicated than an if, if you want to process the error
> immediately. You can use an exception, but it's about like
> pealing a grape with a butcher's cleaver.
To say "they are of no use at all" is incorrect. Someone may prefer that
style (those who think one mechanism only is nirvana comes to mind).
Richard
"Alf P. Steinbach" <al...@start.no> spake the secret code
<hejsud$83s$1...@news.eternal-september.org> thusly:
....which is a good example of why macros are evil.
Alf P. Steinbach
> [Please do not mail me a copy of your followup]
>
> "Alf P. Steinbach" <al...@start.no> spake the secret code
> <hejsud$83s$1...@news.eternal-september.org> thusly:
>
>> * James Kanze:
>>> Yes, but having to write a try block, then a catch statement, is
>>> more complicated than an if, if you want to process the error
>>> immediately. You can use an exception, but it's about like
>>> pealing a grape with a butcher's cleaver.
>> Off the cuff,
>>
>> #define CATCHX( result, f, args ) \
>> do { \
>> try { \
>> result = f args; \
>> } catch( std::exception const& x ) { \
>> result.set_x( x ); \
>> } \
>> } while( false )
>
> ....which is a good example of why macros are evil.
Mostly macros are evil, but your comment for this case makes no sense to me.
Would you care to elaborate a bit on exactly what you mean (if anything).
Cheers,
- Alf
dragan
> On 25 Nov., 12:14, "dragan" <spambus...@prodigy.net> wrote:
>> peter koch wrote:
>>> On 24 Nov., 10:48, James Kanze <james.ka...@gmail.com> wrote:
>>
>>> When not using exceptions, you more or less write the hidden error-
>>> returning path explicitly in your code. In my experience, this often
>>> gives a signicifand increase in source-code size
>>
>> Can you give some numbers?
>
> Not any exact ones, but I have been working in places where exceptions
> were not used (due to some code being quite old and no one caring
> about fixing). Code there typically looked something like:
>
> int func(parm p,std::string &result)
> {
> std::string s;
> int error;
>
> result = func_1(parm,s);
> if (error != OK)
> {
> return error;
> }
> error = func_2(s);
> if (error != OK)
> {
> return error;
> }
> result = s;
> return OK;
> }
>
#define ERROR (-1)
#define OK (0)
#define Try(x) if(x != OK) goto unwind;
#define CatchAll unwind:
// Not the same function as you have cuz I
// don't want to figure out what you were
// doing hypothetically. Adequate for illustration.
// Many variations on the below theme exist
// including masking of setjmp/longjmp etc.
//
int func (parm p)
{
std::string s;
Try(func_1(p, s))
Try(func_2(s))
return OK;
CatchAll
// do cleanup, rollback, recovery, etc. as appropriate
return ERROR;
}
Macros are your friend to make the language conform to YOUR preferences! :)
dragan
Ah. Bad choice of word then to describe that. I think most people who see
"abort" think exit the process or terminate the thread. Even in your example
above though, I wouldn't expect abort to occur unless the situation has been
going on for some time. The server should have preallocated some resources
for use in such situations.
>
>> A very valid pattern is fixing the problem and resuming.
>
> If that's a valid reaction to the error, aborting isn't the
> answer. If the error was a coding error, you can't fix the
> source, recompile the code, and resume, so you abort. If the
> error was insufficient memory due to an overly complicated
> request, you can't simplify the request and resume: you abort
> the operation. (On receiving an "insufficient resources" error,
> of course, the client may try a simpler request.)
>
>> Some version of Windows expands the stack that way: a
>> violation occurs when trying to push beyond the current stack
>> frame and the system catches the error, expands the stack by
>> 4k and continues processing.
>
> (Isn't that how most systems work?
I don't know.
> That's more or less the way
> the old Berkley kernel worked on Sun 3's, and IIRC, PDP-11's
> memory manager unit was designed expressedly to support
> something like this, back in the days before virtual memory.)
>
> I'm not too sure how that's relevant to user code, however. Are
> you saying that if you get std::bad_alloc, you should try to get
> more memory?
See my comment above.
>
> Frankly, out of memory is a special case, and most of the
> programs I've worked on installed a new_handler to abort in such
> cases. Not all, however, and particularly on transaction based
> systems where transactions can require a lot of memory, it often
> makes sense to just abort the transation. I can't think of much
> else you could do: call some system routine to create more
> virtual memory?
Preallocate for use in those times. Could be from an entirely different heap
or something. Or hardware even: a mem card in a PCI-X slot ... possibilities
are endless. EH is application-specific.
Richard
"Alf P. Steinbach" <al...@start.no> spake the secret code
<hekgtv$un9$1...@news.eternal-september.org> thusly:
Macros hiding loops, returns or try/catch blocks are evil IMO.
Alf P. Steinbach
OK.
Then observe:
* The macro doesn't hide a try-catch block. Its name makes it abundantly
clear that it catches an exception.
* The macro doesn't contain a return.
* The macro doesn't contain a loop. Or well, there is what might look like
a loop, but it's just an old well-known syntactical device, to make the
macro invocation function-like wrt. C++ semicolon rules, especially in
if-else constructions.If you're unfamiliar with this then you've learned
something new! :-)
So, none of your evilness indicators are present.
Cheers & hth.,
- Alf
PS: By the way, much of this macro stuff will be unnecessary in C++0x, which
much better supports argument forwarding.
Richard
We can agree to disagree, but I don't like your macro.
Paavo Helde
news:gXkPm.25025$kY2....@newsfe01.iad:
> peter koch wrote:
>> On 25 Nov., 12:14, "dragan" <spambus...@prodigy.net> wrote:
>>> peter koch wrote:
>>>> On 24 Nov., 10:48, James Kanze <james.ka...@gmail.com> wrote:
>>>
>>>> When not using exceptions, you more or less write the hidden error-
>>>> returning path explicitly in your code. In my experience, this
>>>> often gives a signicifand increase in source-code size
>>>
>>> Can you give some numbers?
>>
>> Not any exact ones, but I have been working in places where
>> exceptions were not used (due to some code being quite old and no one
>> caring about fixing). Code there typically looked something like:
>>
>> int func(parm p,std::string &result)
>> {
>> std::string s;
>> int error;
>>
>> result = func_1(parm,s);
>> if (error != OK)
>> {
>> return error;
>> }
>> error = func_2(s);
>> if (error != OK)
>> {
>> return error;
>> }
>> result = s;
>> return OK;
>> }
>>
>
> #define ERROR (-1)
> #define OK (0)
If you are happy writing the above two lines, it shows clearly IMO that
you have never done any large scale development in C++. Consequence: you
have no idea what you are talking about when ranting about exceptions. No
offense, I just want to put things in a more correct perspective.
>
> #define Try(x) if(x != OK) goto unwind;
> #define CatchAll unwind:
>
> // Not the same function as you have cuz I
> // don't want to figure out what you were
> // doing hypothetically. Adequate for illustration.
> // Many variations on the below theme exist
> // including masking of setjmp/longjmp etc.
> //
> int func (parm p)
> {
> std::string s;
> Try(func_1(p, s))
> Try(func_2(s))
> return OK;
>
> CatchAll
> // do cleanup, rollback, recovery, etc. as appropriate
> return ERROR;
> }
>
> Macros are your friend to make the language conform to YOUR
> preferences! :)
A Real Programmer (tm) can write Fortran in any language! Seriously, this
is not really C++. A dedicated cleanup block more reminds Java. And it
still has 6 times more lines than the C++ solution.
Paavo
Vladimir Jovic
A function (or a method) has to have the same crap. This remind more of
C, then C++.
btw take a look at this:
http://www.google.com/search?q=macros+are+evil&btnG=Search+the+C%2B%2B+FAQ&sitesearch=www.parashift.com
Once you really try exceptions, you will laugh at this example.
--
ultrasound www.ezono.com
Vladimir Jovic
Off course, this should have been:
A function (or a method) *that is using this function* has to have the
same crap. This remind more of C, then C++.
--
ultrasound www.ezono.com
peter koch
You just gave a perfect example of how to make bad code worse. Your
code has several issues:
1) You fail to "return" the result when everything goes well.
2) You fail to return the error-code when things go wrong.
3) Your code has reintroduced the hidden paths you dislike about
exceptions.
All this for reducing a function from ten lines to 6 (generously not
counting your macros) compared to the exception-enabled oneliner.
Finally, your system is quite fragile - forbidding its use in some
cases. Change the function slightly, and it becomes ill-formed:
int func (parm p)
{
std::string s1;
Try(func_1(p, s1)) // Ill-formed!
std::string s2;
Try(func_2(s2))
return OK;
CatchAll
// do cleanup, rollback, recovery, etc. as appropriate
return ERROR;
}
So your macro-voodoo not only introduces hidden return-paths. It also
prevents writing idiomatic C++ (if that was not already lost) and
increases the code-size considerably.
/Peter
/Peter
James Kanze
<sgolod...@NdOiSaPlA.pMiPpLeExA.ScEom> wrote:
> >> <snip>
> >> I don't really understand why the violation check's being
> >> done at runtime rather than compile time (the way checked
> >> exceptions in Java work) - the "what should happen if an
> >> unexpected exception is thrown at runtime?" question is
> >> fair enough, but why does it get to that point in the first
> >> place? Is it difficult/impossible to do the check at
> >> compile time in C++? Or is the issue that it would break a
> >> lot of old code where the functions don't have exception
> >> specifications?
> > There are (I think) several reasons. One obvious one is
> > that that if you don't specify anything, the compiler will
> > assume that a function can throw anything, so you'd end up
> > needing a lot of otherwise useless try blocks with legacy
> > code (since the code doesn't declare that it can't throw,
> > but it doesn't in fact ever throw, and you know that).
> I guess you could always go down the Java-like route of
> introducing a checked_exception base class for exceptions
> which can be checked in exception specifications and assuming
> that where legacy code does throw, it throws only unchecked
> exceptions. Not sure this would make things any easier though?
It seems to combine the disadvantages of both. In practice,
most of Java's checked exceptions are things that logically
should be a return code: things that usually have to be handled
locally, by the calling function. At present, C++ does it
better (although IMHO, compile time checking would be better
still, if it weren't for the problem of legacy code): the most
useful guarantee (perhaps the only useful guarantee) is that a
function doesn't exit via an exception, ever. You can't express
this guarantee in Java.
> >The other is the IMHO misguided
> > theory that it would require the programmer to provide
> > additional runtime checks. If, for example, you have a sqrt
> > function with throws if passed a negative value, and you write
> > something like:
> > double
> > checked_sqrt(double in) throw()
> > {
> > return in < 0.0 ? 0.0 : sqrt(in);
> > }
> > you'd need a try block to tell the compiler that you're not
> > going to allow any exceptions to escape. (As I said, I
> > don't actually agree with this reasoning. But it's a reason
> > I've heard cited.)
> Just to clarify: do you think it doesn't need a try block, or
> that that's not a problem? (FWIW, my current answers to those
> would be that I think it does need a try block, but that I
> don't think that's a major problem - but I'm open to
> thoughts.)
I don't think that it would be a problem requiring the try
block. I'm really in favor of static checking. But I've
definitely heard the above argument. (Note that some early
implementations of exceptions and try blocks had some runtime
costs, which might not be acceptable in such a function. I
don't think that this would be an issue with most modern
compilers, however.)
--
James Kanze
James Kanze
> James Kanze wrote:
> > On Nov 25, 11:03 am, "dragan" <spambus...@prodigy.net> wrote:
> >> James Kanze wrote:
> >>> On Nov 23, 8:09 pm, "io_x" <a...@b.c.invalid> wrote:
> >>>> "dragan" ha scritto nel
[....]
> >>> That's the whole point of exceptions. They're for the sort of
> >>> problems where it doesn't matter where the problem occured; the
> >>> handling is the same. If you run out of memory processing a
> >>> request, for example, it doesn't matter where you were in the
> >>> processing when you ran out; you just abort the request (but not
> >>> the process) with an error message, and continue.
> >> You seem to be big on aborting.
> > Attention about word use. There's aborting (in the sense of
> > calling abort()), and aborting (in the more general sense,
> > of immediately terminating some action that you were in the
> > process of doing). In this case, I'm using the other sense:
> > say you've received a request on your LDAP server, and you
> > run out of memory trying to service it (because it requires
> > interpreting some obscenely complicated filter expression,
> > for example). When you detect the lack of memory, you're
> > down in some really deap parsing function, executing
> > operator new. You (or rather the system) raises an
> > std::bad_alloc exception, which you catch at the top level,
> > and abort the request (not the program), returning an error
> > message of "insufficient resources", or the like.
> Ah. Bad choice of word then to describe that.
I didn't invent the language (English). I just use it. I don't
know of any other word for what I described; abort is the
standard word.
> I think most people who see "abort" think exit the process or
> terminate the thread.
I think most people read more than just a word at a time, and
the expression "abort the request" is quite clear. "Abort the
request" is not "abort the process".
> Even in your example above though, I wouldn't expect abort to
> occur unless the situation has been going on for some time.
> The server should have preallocated some resources for use in
> such situations.
I'm not sure I follow. The server will certainly have some
resources preallocated, so that it can successfully log the
error, unwind the stack, and return an error message. But by
definition, it can't use those resources for parsing the
request, or they won't be available for the things they were
reserved for.
> >> A very valid pattern is fixing the problem and resuming.
> > If that's a valid reaction to the error, aborting isn't the
> > answer. If the error was a coding error, you can't fix the
> > source, recompile the code, and resume, so you abort. If
> > the error was insufficient memory due to an overly
> > complicated request, you can't simplify the request and
> > resume: you abort the operation. (On receiving an
> > "insufficient resources" error, of course, the client may
> > try a simpler request.)
> >> Some version of Windows expands the stack that way: a
> >> violation occurs when trying to push beyond the current
> >> stack frame and the system catches the error, expands the
> >> stack by 4k and continues processing.
> > (Isn't that how most systems work?
> I don't know.
> > That's more or less the way the old Berkley kernel worked on
> > Sun 3's, and IIRC, PDP-11's memory manager unit was designed
> > expressedly to support something like this, back in the days
> > before virtual memory.)
> > I'm not too sure how that's relevant to user code, however.
> > Are you saying that if you get std::bad_alloc, you should
> > try to get more memory?
> See my comment above.
Which one? Are you saying that if you get std::bad_alloc, you
should output a message to the terminal, asking the sysop to
insert additional memory chips, and only continue when he does?
> > Frankly, out of memory is a special case, and most of the
> > programs I've worked on installed a new_handler to abort in
> > such cases. Not all, however, and particularly on
> > transaction based systems where transactions can require a
> > lot of memory, it often makes sense to just abort the
> > transation. I can't think of much else you could do: call
> > some system routine to create more virtual memory?
> Preallocate for use in those times. Could be from an entirely
> different heap or something. Or hardware even: a mem card in a
> PCI-X slot ... possibilities are endless. EH is
> application-specific.
Preallocate what? Parsing an LDAP request requires unbounded
memory, since the request can be arbitrarily complicated: the
filter expression can contain any number of parenthesized
sub-expressions. It's just like a C or a C++ compiler: feed it
a file with a function which contains 2 billion nested
parentheses, and see what happens. You can't predict up front
how complex an expression will be, and how much memory you'll
need. Either you arbitrarily limit the complexity (for example,
to prevent stack overflow if you're using recursive descent), or
you handle insufficient memory. Or both: you might normally be
able to handle the expression, but not if a thousand or so
clients send it at the same time.
--
James Kanze
dragan
Once you study the realm that C++ exceptions fall under, you will be
enlightened. It's fine and dandy to just accept things thrown at you in the
form that they are thrown at you. If you are "that kind" though, I wouldn't
want you on my development "team". (You betcha I knew people where going to
drive their cadillacs into that "example" I gave. Have you been "had"?)
dragan
That you thought that I proposed that as an alternative to anything shows
that you are a greenbean, wet behind the ears. :P I'm not here to divulge
proprietary or patentable technology. Deal with it little boy. Cry me a
river because I won't give you my source code. BTW, your mommie called me to
tell you to: GET A CLUE!
dragan
"you have some redeeming quality" in that you recognize history. :/ <-- can
anyone parse this?
dragan
It wasn't an example.
> of how to make bad code worse.
Or how to make people THINK? I mean, you're thinking about it, right?
Success.
> Your
> code has several issues:
>
> 1) You fail to "return" the result when everything goes well.
?? You can't see the "return OK;" statement??
> 2) You fail to return the error-code when things go wrong.
?? You can't see the "return ERROR;" statement?
You "got me": I had to stick in the baggage from the previous poster's
example: std::string. Touche, and: :P. If you were REALLY smart though,
you'd ask, "why is this dude who is avoiding exceptions using
std::string??!". Answer: he wouldn't.
> 3) Your code has reintroduced the hidden paths you dislike about
> exceptions.
>
> All this for reducing a function from ten lines to 6 (generously not
> counting your macros) compared to the exception-enabled oneliner.
>
> Finally, your system is quite fragile - forbidding its use in some
> cases. Change the function slightly, and it becomes ill-formed:
>
> int func (parm p)
> {
> std::string s1;
> Try(func_1(p, s1)) // Ill-formed!
> std::string s2;
> Try(func_2(s2))
> return OK;
>
>
> CatchAll
> // do cleanup, rollback, recovery, etc. as appropriate
> return ERROR;
> }
>
> So your macro-voodoo not only introduces hidden return-paths. It also
> prevents writing idiomatic C++ (if that was not already lost) and
> increases the code-size considerably.
If you like Humvees, but they only were available in pink, maybe you'd
repaint it? Some people would just buy something else. Oh, there IS NOTHING
ELSE you say? Don't be so sure. Is that a corporate Vee you're driving?
Dude, nice COLOR! (hehehe).
dragan
Don't worry about. It's my "second language", but maybe that elicited me to
study it more. I have found no error in you use of English.
> I don't
> know of any other word for what I described; abort is the
> standard word.
It sounds like an "unstudied appropriation". "Hurried". Inappropriate and
incorrect.
>
>> I think most people who see "abort" think exit the process or
>> terminate the thread.
>
> I think most people read more than just a word at a time,
Oh, you know I'm not gonna let you off that easy Mr. (Did you read where I
was spanking the other with such childish tactic? Did he maybe LEARN it from
you??!)
> and
> the expression "abort the request" is quite clear. "Abort the
> request" is not "abort the process".
Noted: your vocabulary is terse so you requisition what you have at your
disposal, hoping that it will be understood (or hoping it will give you a
scapegoat!). I understand the way you think. You are unsure of what to do.
And so, unsure of yourself. But, you KNOW that you can be MORE or "the
bomb". Let's get it done. You're really Elvis, right? I mean really, you
can't hide forever right? Surely you are Elvis. The King!
:/ <-- parse this.
>
>> Even in your example above though, I wouldn't expect abort to
>> occur unless the situation has been going on for some time.
>> The server should have preallocated some resources for use in
>> such situations.
>
> I'm not sure I follow. The server will certainly have some
> resources preallocated, so that it can successfully log the
> error, unwind the stack, and return an error message.
Pfft. Stop already. To cut the convo short: I think I can deploy without C++
exceptions. Any of this "large scale" bullshit, does not apply to me, so
curb it already. Stop being pedantic. (Or not, it's all good: it's my fault
if I get sucked into these USELESS tiradal "discussions").
> But by
> definition, it can't use those resources for parsing the
> request, or they won't be available for the things they were
> reserved for.
Answer: too abstract. I have a real application and don't need to be
thinking about "THE general solution" that will do this that AND cure cancer
as a side effect. Nuff said. If you don't grok that, I don't care, you're
not my problem.
I could call you facetious, but I think you trully are not following the
main points. Your scapegoat is that you follow too many threads. I said
"preallocate", but just like I said that error handling (not "management"
this time) is application-specific, so is that one specific error. I know
those answers. I don't want to entertain discussion or be the bouncing board
for those who only "read the books". No offense, but it's not my thing. And
no, I'm not being "high and mighty", nor am I about to be a whimp. (speaking
of whimps, I noticed you didn't have anything more to say about being WRONG
about "error reporting"). :) :P
>
>>> Frankly, out of memory is a special case, and most of the
>>> programs I've worked on installed a new_handler to abort in
>>> such cases. Not all, however, and particularly on
>>> transaction based systems where transactions can require a
>>> lot of memory, it often makes sense to just abort the
>>> transation. I can't think of much else you could do: call
>>> some system routine to create more virtual memory?
>
>> Preallocate for use in those times. Could be from an entirely
>> different heap or something. Or hardware even: a mem card in a
>> PCI-X slot ... possibilities are endless. EH is
>> application-specific.
>
> Preallocate what?
M-E-M-O-R-Y.
> Parsing an LDAP request requires unbounded
You don't really expect me graft my discussion on your post-conceived
scenario, do you? That would be so "unsporting".
> memory, since the request can be arbitrarily complicated: the
> filter expression can contain any number of parenthesized
> sub-expressions. It's just like a C or a C++ compiler: feed it
> a file with a function which contains 2 billion nested
> parentheses, and see what happens. You can't predict up front
> how complex an expression will be, and how much memory you'll
> need. Either you arbitrarily limit the complexity (for example,
> to prevent stack overflow if you're using recursive descent), or
> you handle insufficient memory. Or both: you might normally be
> able to handle the expression, but not if a thousand or so
> clients send it at the same time.
So, maybe "call me" when you have a PRODUCT like SmartHeap? Else maybe "shut
up"? You don't really think I'd consider hiring you before I'd buy a product
like that, do you? I do it differently, yes. Internally I DO "compete" with
the commercial memory allocator offerings. No offense meant.
Dragan
"English is my second language" :)
peter koch
I was referring to the std::string that was the result of the
computation.
>
> > 2) You fail to return the error-code when things go wrong.
>
> ?? You can't see the "return ERROR;" statement?
>
You are assuming that you can only have one kind of error? In real
life more than one thing can go wrong, the reason being kept in the
return code. That is why you use an int, not a bool.
> You "got me": I had to stick in the baggage from the previous poster's
> example: std::string. Touche, and: :P. If you were REALLY smart though,
> you'd ask, "why is this dude who is avoiding exceptions using
> std::string??!". Answer: he wouldn't.
>
You are welcome to use your own class if that would simplify things.
> > 3) Your code has reintroduced the hidden paths you dislike about
> > exceptions.
>
You forgot to comment about this point.
> > All this for reducing a function from ten lines to 6 (generously not
> > counting your macros) compared to the exception-enabled oneliner.
>
And this one as well.
> > Finally, your system is quite fragile - forbidding its use in some
> > cases. Change the function slightly, and it becomes ill-formed:
>
> > int func (parm p)
> > {
> > std::string s1;
> > Try(func_1(p, s1)) // Ill-formed!
> > std::string s2;
> > Try(func_2(s2))
> > return OK;
>
> > CatchAll
> > // do cleanup, rollback, recovery, etc. as appropriate
> > return ERROR;
> > }
>
> > So your macro-voodoo not only introduces hidden return-paths. It also
> > prevents writing idiomatic C++ (if that was not already lost) and
> > increases the code-size considerably.
>
And also on this one.
> If you like Humvees, but they only were available in pink, maybe you'd
> repaint it? Some people would just buy something else. Oh, there IS NOTHING
> ELSE you say? Don't be so sure. Is that a corporate Vee you're driving?
> Dude, nice COLOR! (hehehe).
I fail to see the analogy. The Humvee is your code - using six lines
of code (plus the macroes) where one suffices, and introducing
unsustainable elements (the hidden gotos as a potential source of ill-
formed code).
/Peter
James Kanze
It is the standard word for this. The C function takes its name
from everyday usage: to abort an action is to terminate it
bruskly. In transaction terminology, it's frequent to speak of
aborting a transaction (which results in a roll-back instead of
a commit); in server technology, it's frequent to speak of
aborting a request. And so on. The C function aborts the
process, but processes are far from the only things which can be
aborted.
> >> I think most people who see "abort" think exit the process
> >> or terminate the thread.
> > I think most people read more than just a word at a time,
> Oh, you know I'm not gonna let you off that easy Mr. (Did you
> read where I was spanking the other with such childish tactic?
> Did he maybe LEARN it from you??!)
> > and the expression "abort the request" is quite clear.
> > "Abort the request" is not "abort the process".
> Noted: your vocabulary is terse so you requisition what you
> have at your disposal, hoping that it will be understood (or
> hoping it will give you a scapegoat!).
Sorry, but in this context, "abort" is the standard word, and
has been pretty much everywhere I've worked. It's also been the
word I've seen used in literature.
> I understand the way you think. You are unsure of what to do.
> And so, unsure of yourself.
You're the first person who's accused me of that:-). I'm
usually accused of being too sure of myself.
[...]
> > Which one? Are you saying that if you get std::bad_alloc,
> > you should output a message to the terminal, asking the
> > sysop to insert additional memory chips, and only continue
> > when he does?
> I could call you facetious, but I think you trully are not
> following the main points. Your scapegoat is that you follow
> too many threads. I said "preallocate", but just like I said
> that error handling (not "management" this time) is
> application-specific, so is that one specific error.
Yes, but I presented a very specific case: parsing an LDAP
request. An LDAP request can be arbitrarily complex, and can
require an arbitrarily large amount of memory. How do you
"pre-allocate" an arbitrary large amount of memory? No matter
how much you pre-allocate, it might not be enough.
[...]
> > Parsing an LDAP request requires unbounded
> You don't really expect me graft my discussion on your
> post-conceived scenario, do you? That would be so
> "unsporting".
In other words, you prefer to ignore issues that you don't
understand.
--
James Kanze
Joshua Maurice
> Paavo Helde wrote:
> > Regarding Google, maybe they might have banned exceptions because of the
> > run-time overhead (just guessing). Throwing exceptions is notoriously
> > slow, so they should not be used unless something goes very wrong - but
> > for a 24/7 service like Google nothing should go wrong ever, so no need
> > for exceptions, right?
>
> Notoriously slow is a pretty vague statement. Exceptions do not slower
> the speed of the code unless they are thrown. So your choices are: slow
> your happy code (that runs a billion times) by inserting hundreds of if
> statements into it to propagate return codes up the call stack to the
> handler, or make returning 1000 times slower 3 times a day... It is a
> no brainer to me.
Sadly no. That was the intent. However, on half of all of the unix-
like environments available for me to test on, including Solaris, AIX,
HPUX, Linux, and for the common windows platforms, win32, win64,
exceptions add overhead even when not thrown, some worse than others.
Windows, for example, implements C++ exceptions on top of their
structured exception handling, which means that you're paying a
penalty every time you enter a try block. For a particularly contrived
test I once wrote, I got performance slowdowns of up to ~1.5x slower
than the version which used error return codes on one platform.
Not that I'm trying to say use exceptions or don't in this post. Just
understand their practical costs and don't repeat (wishful)
misinformation.
Ian Collins
How have you measured? All my tests on Solaris with gcc and Sun CC have
shown the normal execution path to be faster with exceptions than
testing return values.
--
Ian Collins
Joshua Maurice
My tests on Sun 64 with gcc also show that the implementation uses the
"correct" aka "good" aka table approach to implementing exceptions,
resulting in (near) zero overhead. (Sun on x86 is another story.)
Here are my tests first (which I did a year or two ago), giving a
basic description of the platform and the compiler options used. After
will be the code which I ran. Note that I did some marginal care to
make sure I wasn't seeing caching or preloading, but I don't claim
that these numbers are fullproof or otherwise reliable beyond a very
basic eyeball level. Specifically, I wouldn't use these numbers too
much beyond to answer "Does exception presence without ever throwing
cause overhead in C++ on X implementation?"
Note that I ran each test with input numbers to get a wallclock time
of ~30 seconds. Note that the test suite runs the tests in a (pseudo-)
random order to avoid some weird caching or optimization effects I was
seeing. (I think). Note that I do a single run of the individual test
before starting timing to try and minimize artificial caches misses.
Again, I do not claim that these tests are very thorough or robust or
even correct. I think they are.
Note that the compilers I'm using are somewhat old as well. I'm merely
using what my company used to compile our product on these platforms
several years ago. I do hope I used the right compiler options. (I did
some quick google research to determine the command line options.)
The x### is the factor comparing the slower of the two tests "virtual
exception" or "virtual fake try block" vs the test "virtual return
code".
Windows XP Pro 32
using visual studios 2003 32-bit compiler, standard release compiler
options.
Exception using code x1.04
AIX 32
% uname -a
AIX bigpine 2 5 0003DFC3D600
% xlC_r -V
C for AIX Compiler, Version 6
[Rest omitted]
% xlC_r -O4 -qnotempinc foo.cpp
Exception using code x0.94
(Yes. I have no clue why it's smaller, but it was a reproducible
number.)
AIX 64
% uname -a
AIX waco 2 5 00CAEAEA4C00
% xlC_r -V
C for AIX Compiler, Version 6
[Rest omitted]
% xlC_r -O4 -qnotempinc -q64 foo.cpp
Exception using code x1.48
HP 32
[9] % uname -a
HP-UX nimbus B.11.11 U 9000/800 2328359749 unlimited-user license
[10] % aCC -V
aCC: HP ANSI C++ B3910B A.03.73
[11] % aCC -AA -mt -z -ext -Wc,-ansi_for_scope,on +O3 foo.cpp
Exception using code x1.16
HP 64
[9] % uname -a
HP-UX cygnus B.11.11 U 9000/800 2328359751 unlimited-user license
[10] % aCC -V
aCC: HP ANSI C++ B3910B A.03.73
[11] % aCC -AA -mt -z -ext -Wc,-ansi_for_scope,on +O3 +DD64 foo.cpp
Exception using code x1.46
hp ipf
[11] % uname -a
HP-UX texan B.11.23 U ia64 0622264057 unlimited-user license
[12] % aCC -V
aCC: HP aC++/ANSI C B3910B A.06.05 [Jul 25 2005]
[13] % aCC -AA -mt -z -ext -Wc,-ansi_for_scope,on +O3 +DD64
+DSitanium2 foo.cpp
Exception using code x1.27
lin 32
[jmaurice@davey ~/test]$ uname -a
Linux davey.informatica.com 2.6.9-5.ELsmp #1 SMP Wed Jan 5 19:30:39
EST 2005 i686 i686 i386 GNU/Linux
[jmaurice@davey ~/test]$ g++ --version
g++ (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.1)
[Rest omitted]
[jmaurice@nagara ~/test]$ g++ -O3 foo.cpp
Exception using code x1.0
lin 64
[jmaurice@nagara ~/test]$ uname -a
Linux nagara 2.6.9-11.ELsmp #1 SMP Fri May 20 18:25:30 EDT 2005 x86_64
x86_64 x86_64 GNU/Linux
[jmaurice@nagara ~/test]$ g++ --version
g++ (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.1)
[Rest omitted]
[jmaurice@nagara ~/test]$ g++ -O3 foo.cpp
Exception using code x1.0
lin IA 46
[jmaurice@seraph ~/test]$ g++ --version
g++ (GCC) 3.3.1
[Rest omitted]
[jmaurice@seraph ~/test]$ g++ -O3 foo.cpp
Exception using code x1.0
sun 64
[test] uname -a
SunOS mosquito 5.8 Generic_108528-29 sun4u sparc SUNW,Sun-Fire-V440
[test] CC -V
CC: Sun C++ 5.5 2003/03/12
[test] CC -O4 +w +w2 -mt -features=extensions -xarch=generic64 -
xtarget=generic64 foo.cpp
Exception using code x1.0
sun x86
[test] uname -a
SunOS coyote 5.10 Generic_Patch_118844-30 i86pc i386 i86pc
[test] CC -V
CC: Sun C++ 5.8 2005/10/13
[test] CC -O4 +w +w2 -mt -features=extensions foo.cpp
Exception using code x1.05
////
//Start test
#include <cstdlib>
#include <ctime>
#include <iomanip>
#include <iostream>
#include <sstream>
#include <string>
#include <vector>
using namespace std;
enum ReturnCodeT { Success = 1, Failure = 2 };
class TestInterface
{
public:
virtual void virtualCanThrow(int a, int b, int targetSum) = 0;
virtual ReturnCodeT virtualReturnCode(int a, int b, int targetSum)
= 0;
ReturnCodeT inlineableReturnCode(int a, int b, int targetSum)
{ if (a + b == targetSum)
return Failure;
return Success;
}
};
inline ReturnCodeT globalInlineableReturnCode(int a, int b, int
targetSum)
{ if (a + b == targetSum)
return Failure;
return Success;
}
class TestImpl : public TestInterface
{
public:
virtual void virtualCanThrow(int a, int b, int targetSum)
{ if (a + b == targetSum)
throw 1;
}
virtual ReturnCodeT virtualReturnCode(int a, int b, int targetSum)
{ if (a + b == targetSum)
return Failure;
return Success;
}
};
class TestImpl2 : public TestInterface
{
public:
virtual void virtualCanThrow(int a, int b, int targetSum)
{ cout << "XXX" << endl;
}
virtual ReturnCodeT virtualReturnCode(int a, int b, int targetSum)
{ cout << "XXX" << endl;
return Success;
}
};
void testInlineableMemberReturnCode(TestInterface *& x, int arg1, int
arg2)
{ { vector<int> vec;
for (int i=0; i<arg1; ++i)
{ for (int j=0; j<arg1; ++j)
{ //vec.push_back(i+j);
if (Failure == x->inlineableReturnCode(i, j, arg2+3))
{ cout << "inlineable member return code, returned
failure" << endl;
x = new TestImpl2();
}
}
}
if (vec.size() && vec.back() == arg2+3)
{ cout << "inlineable member return code, vector size
comparison true" << endl;
x = new TestImpl2();
}
}
}
void testInlineableGlobalReturnCode(TestInterface *& x, int arg1, int
arg2)
{ { vector<int> vec;
for (int i=0; i<arg1; ++i)
for (int j=0; j<arg1; ++j)
{ //vec.push_back(i+j);
if (Failure == globalInlineableReturnCode(i, j,
arg2+4))
cout << "inlineable global return code, returned
failure" << endl;
}
if (vec.size() && vec.back() == arg2+4)
cout << "inlineable global return code, vector size
comparison true" << endl;
}
}
void testVirtualReturnCodeFakeTry(TestInterface *& x, int arg1, int
arg2)
{ { vector<int> vec;
for (int i=0; i<arg1; ++i)
{ for (int j=0; j<arg1; ++j)
{ //vec.push_back(i+j);
try
{ if (Failure == x->virtualReturnCode(i, j, arg2+5))
{ cout << "virtual return code with fake try,
returned failure" << endl;
x = new TestImpl2();
}
} catch (...)
{ cout << "ERROR impossible exception caught" <<
endl;
x = new TestImpl2();
}
}
}
if (vec.size() && vec.back() == arg2+5)
{ cout << "virtual return code with fake try, vector size
comparison true" << endl;
x = new TestImpl2();
}
}
}
void testVirtualReturnCode(TestInterface *& x, int arg1, int arg2)
{ { vector<int> vec;
for (int i=0; i<arg1; ++i)
{ for (int j=0; j<arg1; ++j)
{ //vec.push_back(i+j);
if (Failure == x->virtualReturnCode(i, j, arg2+6))
{ cout << "virtual return code, returned failure" <<
endl;
x = new TestImpl2();
}
}
}
if (vec.size() && vec.back() == arg2+6)
{ cout << "virtual return code, vector size comparison true"
<< endl;
x = new TestImpl2();
}
}
}
void testVirtualException(TestInterface *& x, int arg1, int arg2)
{ { vector<int> vec;
for (int i=0; i<arg1; ++i)
{ for (int j=0; j<arg1; ++j)
{ //vec.push_back(i+j);
try
{ x->virtualCanThrow(i, j, arg2+7);
} catch (int & )
{ cout << "virtual exception, exception caught" <<
endl;
x = new TestImpl2();
}
}
}
if (vec.size() && vec.back() == arg2+7)
{ cout << "virtual exception, vector size comparison true"
<< endl;
x = new TestImpl2();
}
}
}
void testManuallyInlinedReturnCode(TestInterface *& x, int arg1, int
arg2)
{ { vector<int> vec;
for (int i=0; i<arg1; ++i)
{ for (int j=0; j<arg1; ++j)
{ //vec.push_back(i+j);
ReturnCodeT retVal;
if (i + j == arg2+8)
retVal = Failure;
else
retVal = Success;
if (retVal == Failure)
{ cout << "manually inlined return code, failure
'returned'" << endl;
x = new TestImpl2();
}
}
}
if (vec.size() && vec.back() == arg2+8)
{ cout << "manually inlined return code, vector size
comparison true" << endl;
x = new TestImpl2();
}
}
}
void testManuallyInlinedOptimizedReturnCode(TestInterface *& x, int
arg1, int arg2)
{ { vector<int> vec;
for (int i=0; i<arg1; ++i)
for (int j=0; j<arg1; ++j)
{ //vec.push_back(i+j);
if (i + j == arg2+9)
{ cout << "manually inlined and optimized return
code, failure 'returned'" << endl;
x = new TestImpl2();
}
}
if (vec.size() && vec.back() == arg2+9)
{ cout << "manually inlined and optimized return code,
vector size comparison true" << endl;
x = new TestImpl2();
}
}
}
int main(int argc, char ** argv)
{
if (argc != 3 && argc != 4)
return 1;
int arg1;
if (! (stringstream(argv[1]) >> arg1))
return 1;
int arg2;
if (! (stringstream(argv[2]) >> arg2))
return 1;
TestInterface * x;
if (argc == 3)
x = new TestImpl();
else
x = new TestImpl2();
vector<clock_t> retVal;
typedef void (*TestFuncType)(TestInterface *&, int, int);
vector<pair<string, TestFuncType> > remainingTests;
remainingTests.push_back(make_pair(string("Inlineable Member
Return Code"), & testInlineableMemberReturnCode));
remainingTests.push_back(make_pair(string("Inlineable Global
Return Code"), & testInlineableGlobalReturnCode));
remainingTests.push_back(make_pair(string("Virtual Return Code
Fake Try"), & testVirtualReturnCodeFakeTry));
remainingTests.push_back(make_pair(string("Virtual Return
Code"), & testVirtualReturnCode));
remainingTests.push_back(make_pair(string("Virtual
Exception"), & testVirtualException));
remainingTests.push_back(make_pair(string("Manually Inlined Return
Code"), & testManuallyInlinedReturnCode));
remainingTests.push_back(make_pair(string("Manually Inlined
Optimized Return Code"), & testManuallyInlinedOptimizedReturnCode));
srand(time(0));
while (remainingTests.size())
{
int index = rand() % remainingTests.size();
pair<string, TestFuncType> thisTest = remainingTests[index];
remainingTests.erase(remainingTests.begin() + index);
clock_t t0 = clock();
(*thisTest.second)(x, 1, -10);
clock_t t1 = clock();
(*thisTest.second)(x, arg1, arg2);
clock_t t2 = clock();
cout << setw(40) << thisTest.first << " : " << double(t2 -
t1) / double(CLOCKS_PER_SEC) << endl;
}
}
Joshua Maurice
% ./a.out 30000 -10
or
% ./a.out ${number} -10
Joshua Maurice
However, on half of all of the unix-
> like environments available for me to test on, including Solaris, AIX,
> HPUX, Linux, and for the common windows platforms, win32, win64,
> exceptions add overhead even when not thrown, some worse than others.
That should read "I have done tests on X platforms, and of those X,
roughly half implement exceptions the slow aka bad aka not table way",
not "The listed platforms are all bad." Some of the listed platforms
implement exceptions the good way. See earlier posts. Sorry for the
confusion.
Joshua Maurice
> lin IA 46
> [jmaurice@seraph ~/test]$ g++ --version
> g++ (GCC) 3.3.1
> [Rest omitted]
> [jmaurice@seraph ~/test]$ g++ -O3 foo.cpp
> Exception using code x1.0
Ack again. I just copied and pasted something I had lying around, and
apparently it was in error. That's supposed to be "lin IA 64", and I
missed the "uname -a" results.
[jmaurice@seraph ~]$ uname -a
Linux seraph 2.6.9-34.EL #1 SMP Fri Feb 24 16:49:08 EST 2006 ia64 ia64
ia64 GNU/Linux
Sorry. It's late for me, and I wanted to be prompt with my reply for
the curious Ian Collins.
Bo Persson
> On Nov 20, 8:09 pm, White Wolf <wo...@freemail.hu> wrote:
>> Paavo Helde wrote:
>>> Regarding Google, maybe they might have banned exceptions because
>>> of the run-time overhead (just guessing). Throwing exceptions is
>>> notoriously slow, so they should not be used unless something
>>> goes very wrong - but for a 24/7 service like Google nothing
>>> should go wrong ever, so no need for exceptions, right?
>>
>> Notoriously slow is a pretty vague statement. Exceptions do not
>> slower the speed of the code unless they are thrown. So your
>> choices are: slow your happy code (that runs a billion times) by
>> inserting hundreds of if statements into it to propagate return
>> codes up the call stack to the handler, or make returning 1000
>> times slower 3 times a day... It is a no brainer to me.
>
> Sadly no. That was the intent. However, on half of all of the unix-
> like environments available for me to test on, including Solaris,
> AIX, HPUX, Linux, and for the common windows platforms, win32,
> win64, exceptions add overhead even when not thrown, some worse
> than others. Windows, for example, implements C++ exceptions on top
> of their structured exception handling, which means that you're
> paying a penalty every time you enter a try block.
That's true for win32, but not for win64.
>
> Not that I'm trying to say use exceptions or don't in this post.
> Just understand their practical costs and don't repeat (wishful)
> misinformation.
Right! :-)
Bo Persson
Thomas J. Gritzan
You only have Win32 in your list, but not Win64 on either IA64 nor AMD64.
Do you have numbers for those, too?
--
Thomas
Joshua Maurice
wrote:
Not offhand. I could run tests for them potentially when I get some
spare time. I have been told or read that the win64 platform has a
different ABI which handles exceptions different, the correct way,
unlike win32. I know nothing of win IA 64 or win AMD 64. .
White Wolf
My tests on Linux, Windows and Solaris has shown different results than
yours.
Thomas J. Gritzan
> On Nov 28, 8:56 am, "Thomas J. Gritzan" <phygon_antis...@gmx.de>
> wrote:
>> Joshua Maurice schrieb:
>>
>>> On Nov 27, 11:48 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>>> However, on half of all of the unix-
>>>> like environments available for me to test on, including Solaris, AIX,
>>>> HPUX, Linux, and for the common windows platforms, win32, win64,
>>>> exceptions add overhead even when not thrown, some worse than others.
>>> That should read "I have done tests on X platforms, and of those X,
>>> roughly half implement exceptions the slow aka bad aka not table way",
>>> not "The listed platforms are all bad." Some of the listed platforms
>>> implement exceptions the good way. See earlier posts. Sorry for the
>>> confusion.
>> You only have Win32 in your list, but not Win64 on either IA64 nor AMD64.
>>
>> Do you have numbers for those, too?
>
> Not offhand. I could run tests for them potentially when I get some
> spare time. I have been told or read that the win64 platform has a
> different ABI which handles exceptions different, the correct way,
> unlike win32.
I also read that the ABI changed to table-based exceptions in Windows
for AMD64. I guess they won't change it for Win32, as it would break
some code (or binary compatibility on library interfaces); and it
doesn't matter to them because too few customers use exceptions.
> I know nothing of win IA 64 or win AMD 64. .
You list lin 32, lin 64 and lin IA64, where uname says:
1) i386
2) x86_64
3) ia64
No. 1 is the known Intel x86 compatible desktop architecture.
No. 2 is the 64-bit extension of it developed by AMD and licensed by
Intel (sometimes called AMD64).
No. 3 is the 64-bit server architecture also known as Itanium.
Windows also runs on all three, and each is another platform on its own
with a different ABI. So it's ambiguous to say Win64, or "the 64-bit
Windows platform", as there are two.
--
Thomas
Joshua Maurice
> Joshua Maurice wrote:
> > Not that I'm trying to say use exceptions or don't in this post. Just
> > understand their practical costs and don't repeat (wishful)
> > misinformation.
>
> My tests on Linux, Windows and Solaris has shown different results than
> yours.
I'm curious as to your test code and testing methods, exact numbers,
uname -a, OS version, compiler version, and compiler (and linker)
options. What are your results?