What about:

if( !read(&b,4) ||
    !read(&c,10) ||
    !read(&d,13) ||
    !read(&e,3) ||
    !read(&f,14) )
{
    return false;
}

Sean Kelly wrote:

>> int x = func(); //ok
>> func(); //error
> 
> Why?  The user should always have the option of ignoring error conditions, even to his own detriment.

They still would:

cast(void) func();

>  Besides, with exceptions I could always do this:
> try{ funcThatThrows(); }
> catch( ... ) {}

Yes, but at least it makes it verbose.

> Using exceptions for flow control creates difficult situations as it prevents the user from easily separating expected failure conditions from exceptional ones.  The extreme example of this is the bit of code above where every function call is wrapped in a try block in order to preserve execution flow, and consequently might ignore truly diastorous errors, like out of memory conditions.

That would be good to avoid. :>

-eye

It is not clear in what order the reads are being executed.

And may be you want to do some stuff in between .

-- 
Jan-Eric Duden
"Sean Kelly" <sean@ffwd.cx> wrote in message
news:c1om5f$oas$1@digitaldaemon.com...
> What about:
>
> if( !read(&b,4) ||
>      !read(&c,10) ||
>      !read(&d,13) ||
>      !read(&e,3) ||
>      !read(&f,14) )
> {
>      return false;
> }
>

Jan-Eric Duden wrote:

>It is not clear in what order the reads are being executed.
>
>  
>
It is perfectly clear.

>And may be you want to do some stuff in between.
>  
>
That is a good point.

-- 
-Anderson: http://badmama.com.au/~anderson/

Matthew wrote:
> Exceptions should be reserved for exceptional conditions.
> 
> An eof condition is not exceptional; it is expected any time one reads from
> an input stream, so I would say it does not warrant an exception.

Actually EOF is often an exceptional condition. In most binary file formats you know exactly how much data you need/want to read, since they often follow a pretty strict protocol. For example, there are often length fields describing how many bytes of data follow. So if less bytes are read then it means that the file is corrupted and an exception should be thrown.

Also, speaking from my own experiences, lots of porgrammers never bother to check the return value of a read. If read throws an exception at least the caller can catch it and know that the function failed instead of getting a random result caused by uninitialized memory.

My stream classes all have two kinds of read functions: one that throws an exception if less bytes are read (which I use most of the time) and one that returns the number of bytes read. The latter one is usually only used for files with a "loose" structure, i.e. files that have points where futher data might or might not follow.

Hauke

Jan-Eric Duden wrote:

> Consider following pseude-code :
> 
> try
> {
>     read(&b,4);
>     read(&c,10);
>     read(&d,13);
>     read(&e,3);
>     read(&f,14);
> }
> catch(readexception)
> {
> 
> }
> 
> and:
>     if(!read(&b,4))
>         return false;
>     if(!read(&c,10))
>         return false;
>     if(!read(&d,13))
>         return false;
>     if(!read(&e,3))
>         return false;
>     if(!read(&f,14))
>         return false;
> 
> 
> I would say the first variant looks more elegant and behaves better when
> changes need to be made to the code.
> 

could you not justwrite a myread function which wraps read and throws your exception if its required and then call that instead of read directly?

Of course, i could write my own 'non-standard' stream library...
which fixes all the problems but then it is not the standard stream library
and won't help other people
to prevent bugs.
-- 
Jan-Eric Duden
"X Bunny" <xbunny@eidosnet.co.uk> wrote in message
news:c1rjmu$2r77$1@digitaldaemon.com...
> Jan-Eric Duden wrote:
>
> > Consider following pseude-code :
> >
> > try
> > {
> >     read(&b,4);
> >     read(&c,10);
> >     read(&d,13);
> >     read(&e,3);
> >     read(&f,14);
> > }
> > catch(readexception)
> > {
> >
> > }
> >
> > and:
> >     if(!read(&b,4))
> >         return false;
> >     if(!read(&c,10))
> >         return false;
> >     if(!read(&d,13))
> >         return false;
> >     if(!read(&e,3))
> >         return false;
> >     if(!read(&f,14))
> >         return false;
> >
> >
> > I would say the first variant looks more elegant and behaves better when changes need to be made to the code.
> >
>
> could you not justwrite a myread function which wraps read and throws your exception if its required and then call that instead of read
directly?
>

>if( !read(&b,4) ||
>     !read(&c,10) ||
>     !read(&d,13) ||
>     !read(&e,3) ||
>     !read(&f,14) )
>{
>     return false;
>}
> >It is not clear in what order the reads are being executed.
> >
> >
> >
> It is perfectly clear.

Is that order defined in the language specification?

-- 
Jan-Eric Duden
"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
news:c1qhut$umj$4@digitaldaemon.com...
> Jan-Eric Duden wrote:
>
> >It is not clear in what order the reads are being executed.
> >
> >
> >
> It is perfectly clear.
>
> >And may be you want to do some stuff in between.
> >
> >
> That is a good point.
>
> -- 
> -Anderson: http://badmama.com.au/~anderson/

Jan-Eric Duden wrote:

>>if( !read(&b,4) ||
>>    !read(&c,10) ||
>>    !read(&d,13) ||
>>    !read(&e,3) ||
>>    !read(&f,14) )
>>{
>>    return false;
>>}
>>    
>>
>>>It is not clear in what order the reads are being executed.
>>>
>>>
>>>
>>>      
>>>
>>It is perfectly clear.
>>    
>>
>
>Is that order defined in the language specification?
>
>  
>
Yep (part of the C specification which is carried on to D), the || is a short circuit, so it must go in the order given.  If !read(&b,4), it must stop there.  However, if you used | then it would need to test everything in the sequence regardless.  If there wasn't this certainly, the short circuit would be useless. 

Note that in some cases the compiler can optimise short circuits, but only when it can be absolutely sure that there will be no side effect, so that is no problem.

-- 
-Anderson: http://badmama.com.au/~anderson/

Jan-Eric Duden wrote:

> Of course, i could write my own 'non-standard' stream library...
> which fixes all the problems but then it is not the standard stream library
> and won't help other people
> to prevent bugs.

Thats the crux of it really. You think by having this feature it will help people to prevent bugs. I disagree because it introduces yet another level of complexity were it isnt required leading to bugs that way. I agree that if that addition complexity is required then it could be part of another library not the standard streams.