Re: problem a function
On Mar 4, 12:23 am, Jeff Schwab <j...@schwabcenter.com> wrote:
ZikO wrote:
I recently made a little program which generates ASCII file
for another program. One of the functions there generates
number and returns that as double:
double getNumber(...) {
// code
return double(...);
}
If in the function something goes wrong I return 0.0.
Although it's working for my little program very well I
found that I might need 0 as a proper returned value. What
am I supposed to do to "inform"/indicate that something is
wrong in function if it can return everything even 0?
What you've just said is, "I need a separate return path for
error-reporting, and I'm trying to fake one by returning an
out-of-band value through the regular return path."
No he didn't. What he said is that he needs a unique value to
indicate an error condition. Or rather, that the function
returns two pieces of information: whether it has succeeded or
not, and if it succeeds, the value.
You don't have to fake it, though, because C++ provides a
separate return path especially for errors: The exception
mechanism.
If the errors are "exceptional", and should be handled far from
the calling site, this is the appropriate solution. If the
error is something more or less expected from time to time, and
must be handled immediately in the calling function, returning a
Fallible is probably a better solution.
Libraries that don't offer exceptions, e.g. POSIX, typically
require the client to check the return value, then possibly a
quasi-global error code, after every library call. An
alternative is to cram two values into one; this is how we get
nonsense like getchar returning int.
I wouldn't take Posix as an example of good design. There's a
lot of historical garbage in there.
The fact that getchar returns int, however, isn't part of it.
First, of course, its not Posix, per se, but C---it's part of
Posix because Posix incorporates the C standard. More to the
point, however, if you'll look at any parsing algorithms, you'll
find that they work best if end of input is just another
character. In this case, defining the function to return 257
possible values (rather than the 256 characters) is a very good
idea---especially since all of the functions in <ctype.h> accept
all 257 values. (Allowing plain char to be signed, of course,
was a very bad idea, since it means that the results of
converting the return value of getchar() into a char, even after
checking for EOF, are implementation defined. And may result in
an implementation defined signal being raised.)
Exceptions are great. Once you throw, you never return.
Which isn't always what is wanted. Exceptions are great for
what they were designed to do, but one size doesn't fit all.
Without knowing more about what type of errors he's talking
about and how they should be handled, we can't say whether
exceptions are the best solution or not.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34