[openbeos] Re: B_TRUE/B_FALSE

  • From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sun, 21 Sep 2003 15:38:36 +0200

On 2003-09-21 at 14:52:24 [+0200], Jonas Sundstrom wrote:
> Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
>  ...
> > Another option is then to use a boolean output parameter and return a
> > status_t instead, but output parameters are just annoying.
>  ...
> > #define B_FALSE 0
> > #define B_TRUE 1
> > 
> > then, one could just return a status_t for the function, check for
> > "<>  B_OK" to see if an error occurred
>  ...
> > (yielding a hopefully useful error code if so),
> > and if not, check against B_TRUE or B_FALSE to see what the
> > result of the function was.
> 
> You'd have to check for status < 0,  since B_OK would clash with
> B_FALSE,

I guess, your mailer screwed it up, since Tyler's original text was 
`...check for "< B_OK"...'. :-P

> You'd want to catch all errors, so you can't do an if (status ==
> B_ERROR).
> (B_ERROR is -1, IIRC.) You'd miss the range of explicit error
> conditions.
> 
> One could of course pick numbers that don't clash with B_OK.
> 
> #define B_FALSE 9
> #define B_TRUE 10
> 
> Or keep true/false as they are, to avoid confusion and mistakes,
> and introduce a non-zero B_BOOLEAN_OK, or something.

There actually is no clash, since B_OK wouldn't be a valid return value. 
It's either an error code in case of an error, or a useful value. E.g. a 
return value of 0 for a ssize_t means 0 not B_OK (cf. BDataIO:Read()).

> Or use reference paraments like you, and Ingo, said.

Definitely the best choice. ;-)

> (Isn't it unusual for a boolean function to fail, I mean, it's either
> true or false..
>  Perhaps it shouldn't have been a boolean in the first place?)

Well, there are already a couple of ambigious situations. Just take 
BVolume::IsReadOnly for example. If the object isn't properly initialized, 
false is returned, too, but actually that's an error condition. One could 
say, that the caller should invoke InitCheck() before to check whether the 
object is initialized, but even then there's a race condition, if the 
volume is just unmounted inbetween the calls.
I suspect, that other examples of this kind are equally harmless, though. 
Which is probably why convenience is chosen over correctness.

CU, Ingo

Other related posts: