Re: Allowing return vals not to be checked: a language flaw?
On 24 Feb., 02:23, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Timo Geusch" <tim...@gmail.com> wrote in message
news:1172237760.348291.272940@a75g2000cwd.googlegroups.com...
On Feb 23, 9:39 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
The possibility of error code return vals not being checked has been
used as
one (if not THE) justification for introducing exceptions into C++.
While
"exploding return codes" can aleviate this condition somewhat, they are
not
a panacea.
1. Wouldn't it be good to make it illegal in the language spec to
disallow
unchecked return vals?
Just out of interest, what's the reasoning behind this question?
To make code that uses error return codes more robust. Note that in any
given application program, both return codes and C++ exceptions could be
present. "Use return codes when you can and use exceptions when you have
to"
sounds like a worthy pursuit.
That is very bad advice. It should be the other way around: Use
exceptions when you can and return codes when you have to. The
situations where you have to use return codes are (among others) code
where profiling has shown exception handling to be to slow, where code
has to interface to external code (e.g. C or COM), and code where
exceptions are deemed to be inappropriate (e.g. it is not really an
exception but something "expected").
As it is today, with the ignoring of return
vals allowed, using return codes is hazardous. If there was a new return
type introduced that could not be ignored, it would "robusticize" the
technique.
What makes code more robust is readable code. Having to write explicit
errorchecking code is not something that improves readability.
/Peter
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]