Re: Allowing return vals not to be checked: a language flaw?
JohnQ wrote:
"James Kanze" <james.kanze@gmail.com> wrote in message
news:1172404874.269182.172110@p10g2000cwp.googlegroups.com...
On Feb 24, 6:40 pm, "peter koch larsen" <peter.koch.lar...@gmail.com>
wrote:
On 24 Feb., 02:21, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:> "peter koch larsen" <peter.koch.lar...@gmail.com> wrote in
messagenews:1172229485.225308.311330@v33g2000cwv.googlegroups.com...> >
On
Feb 23, 10:39 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
1. Wouldn't it be good to make it illegal in the language spec to
disallow
unchecked return vals?
Why?
To enable developers to write better error handling code
(mechanism, not policy).
The better errorhandling mechanism is already here. It is called
exceptions.
But exceptions aren't always the best way of reporting an error.
They're really only for "exceptional" cases. (More accurately,
of course, they're for cases where you can reasonably know that
the error cannot be handled immediately by the caller.)
C++ has a number of error reporting mechanisms, intentionally
(because one size doesn't fit all). Some are really only
appropriate in very unusual cases, but three are pretty widely
useful: return codes, exceptions and aborting. It's actually
pretty hard to imagine a complete application which doesn't need
all three.
That's an odd classfication you made: "error reporting mechanisms [...]
return codes, exceptions and aborting".
It's pretty much the consensus among the experts. There are
other mechanisms as well, but they are used only in special
cases. (IOstream, for example, sets internal state, which you
have to check separately. It's the correct idiom for iostream,
but I can't think of any other cases you'd want to do this.)
How I see it:
Error handling mechanism: C++ exceptions.
Exceptions aren't an error handling mechanism. They're an error
reporting mechanism. The code you put in the catch block is the
error handling mechanism. In a larger sense, error handling
includes three parts: error detection, error reporting, and
the error handling itself. Exceptions are one of the options
available for error reporting. They are not the only one.
Because the use of return values can be used to return an
error code doesn't it qualify it a "bonafied EH mechanism" IMO
because it seems like just a technique used while there is no
robustness of a real mechanism.
Anything which gets the job done is a mechanism to do it. The
iostate flags in ios_base are also an error reporting mechanism.
The fact that return values can also be used for other things
doesn't mean that they aren't also an error reporting mechanism.
(It does mean that if they are used for something else, then
this error reporting mechanism may not be available.)
That is, if the standard guaranteed that the return value
would be checked, that would elevate it's status to a "real"
EH mechanism. It's decidedly a fragile technique.
You can ignore exceptions too. (The worst code I've seen, with
regards to ignoring errors, was in Java. Where exceptions are
pretty much the only mechanism.)
A mechanism is something that you use to get the job done.
Return codes are an error reporting mechanism; in a lot of
cases, they are even the preferred mechanism.
Finally, "abort" is just one possibile way to handle an error.
I wouldn't call it either a reporting or handling mechanism.
It's a bit brutal, since it can't be intercepted, and thus, the
error handling can't be done in the process itself. But it
definitly reports an error to the system, which the system will
handle. (Again, it doesn't detect the error, and it doesn't
handle it itself.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]