Re: Allowing return vals not to be checked: a language flaw?
On Feb 27, 11:29 pm, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:1172568989.921171.239080@8g2000cwh.googlegroups.com...
JohnQ wrote:
"James Kanze" <james.ka...@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.
Well I don't agree with "them" then. I consider reporting as a subcategory
of handling ("handling" in the strict sense in this case rather than in the
general usage case of "error handling" which means the whole ball of wax
from detection to handling), as that is just one way to handle an error.
Another way is to abort.
It may be a language problem; "error handling" can have two
meanings. Exceptions, however, are a means of reporting errors;
they neither detect them, nor "handle" them in the stricter
sense of doing whatever needs to be done. The same thing is
true about return codes: you can use them to report an error,
but there is no way that they will detect one, nor do any
processing to recover from one.
One can argue that abort() does contain some handling; it makes
the decision, at least, that the error will not be handled in
the process itself.
How I see it:
Error handling mechanism: C++ exceptions.
Exceptions aren't an error handling mechanism.
But I meant the whole subsystem of C++ exceptions (in contrast
to the other 2 things you grouped together remember).
The subsystem of C++ exceptions is throw/catch. Transmitting
the error from where it was detected to where it will be
handled. There is nothing in exceptions which help in detecting
an error, and there is nothing in them which help in actually
handling it.
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.
Yes, that's how I meant it.
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.
It's more like an ad hoc technique than a well-thought out robust mechanism
for (!) ERROR handling. (Emphasized because it's ironic that an error
handling technique is inherently error-prone as implemented).
It may be ad hoc, but that doesn't change the fact that it is a
mechanism which can, and frequently is, used to report errors.
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.)
My point about the return-value-as-error-code technique is that it is
curiously not robust when apparently it wouldn't be too hard to make it so.
I suppose that the language could be extended to distinguish
between error reporting return values (which can't be ignored),
and others. I know of no language which does this, however, and
in practice, it probably isn't worth the bother.
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.)
Well not entirely. Eventually something will catch the exception. A program
could keep running in an undefined state if a returned error code was not
checked.
Which is exactly what happens in Swing. Something catches the
exception, but the fact that an exception has been caught
doesn't mean that it has been handled.
Similarly, a special error code return value type won't
guarantee correct handling. People will just write:
int ignore = f() ;
and go on; the return code has been "captured", but the error
still hasn't been handled.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, 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! ]