As part of a D Servlet container, I'm putting together yet-another IO package that follows the Java approach more closely (separate input and output streams, with decorator-style filters).

I'd like to solicit opinion on whether it should remain "traditional"
regarding an eof (-1) return from the read() methods, or whether it should
migrate to an EofException strategy?

Boundary-condition examples would be particularly appreciated.

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.

"Kris" <someidiot@earthlink.net> wrote in message news:c1o3dk$2mr1$1@digitaldaemon.com...
> As part of a D Servlet container, I'm putting together yet-another IO package that follows the Java approach more closely (separate input and output streams, with decorator-style filters).
>
> I'd like to solicit opinion on whether it should remain "traditional"
> regarding an eof (-1) return from the read() methods, or whether it should
> migrate to an EofException strategy?
>
> Boundary-condition examples would be particularly appreciated.
>
>

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.

Definately.  Java is slightly broken in this respect, as it tends to want to use exceptions for flow control.

Sean

Sean Kelly wrote:
> 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.
> 
> 
> Definately.  Java is slightly broken in this respect, as it tends to want to use exceptions for flow control.
> 
> Sean
> 

Exceptions should be exceptions and have not to appear in normal control flow. Maybe we should invent something new.....

Stephan Wienczny wrote:

> Exceptions should be exceptions and have not to appear in normal control flow. Maybe we should invent something new.....

In what extent? EOF is something a user *MUST* check, as opposed to an exception which can be passed upwards. So i would believe a return value is most desirable. If the user tries to read past EOF, he should get an exception anyway. :>

The difference is probably in the fact that Java's exceptions *must* be caught, or if they are promoted, then explicitly.

-eye

Kris wrote:
> As part of a D Servlet container, I'm putting together yet-another IO
> package that follows the Java approach more closely (separate input and
> output streams, with decorator-style filters).
> 
> I'd like to solicit opinion on whether it should remain "traditional"
> regarding an eof (-1) return from the read() methods, or whether it should
> migrate to an EofException strategy?
> 
> Boundary-condition examples would be particularly appreciated.

I kind of like how the current std.stream handles this.  read works like the C fread, returning the number of bytes read.  readExact raises an exception if the number of bytes read is not equal to the number asked for.  This way you're given the freedom to deal with it however you like.

Maybe a 'strict' decorator that achieves this functionality is in order.

 -- andy

Ilya Minkov wrote:

> Stephan Wienczny wrote:
>
>> Exceptions should be exceptions and have not to appear in normal control flow. Maybe we should invent something new.....
>
>
> In what extent? EOF is something a user *MUST* check, as opposed to an exception which can be passed upwards. 

Actually, if the user is apsolutly sure that they know the size of the file, they don't need to check for EOF. For example if they are just reading of the first few lines. Actually in that case the overflow exception is useful.

> So i would believe a return value is most desirable. If the user tries to read past EOF, he should get an exception anyway. :>

Sure, because you are not forced to check the return value.  But that does bring up a point. Parhaps in some cases you should be forced to check the return value (use).  ie

checked int func() { }

int x = func(); //ok
func(); //error

> The difference is probably in the fact that Java's exceptions *must* be caught, or if they are promoted, then explicitly.
>
> -eye

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

J Anderson wrote:
>
> Sure, because you are not forced to check the return value.  But that does bring up a point. Parhaps in some cases you should be forced to check the return value (use).  ie
> 
> checked int func() { }
> 
> int x = func(); //ok
> func(); //error

Why?  The user should always have the option of ignoring error conditions, even to his own detriment.  Besides, with exceptions I could always do this:

try{ funcThatThrows(); }
catch( ... ) {}

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.


Sean

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.

-- 
Jan-Eric Duden
"Ilya Minkov" <minkov@cs.tum.edu> wrote in message
news:c1oe20$9b3$1@digitaldaemon.com...
> Stephan Wienczny wrote:
>
> > Exceptions should be exceptions and have not to appear in normal control flow. Maybe we should invent something new.....
>
> In what extent? EOF is something a user *MUST* check, as opposed to an exception which can be passed upwards. So i would believe a return value is most desirable. If the user tries to read past EOF, he should get an exception anyway. :>
>
> The difference is probably in the fact that Java's exceptions *must* be caught, or if they are promoted, then explicitly.
>
> -eye

Sean Kelly wrote:

> J Anderson wrote:
>
>>
>> Sure, because you are not forced to check the return value.  But that does bring up a point. Parhaps in some cases you should be forced to check the return value (use).  ie
>>
>> checked int func() { }
>>
>> int x = func(); //ok
>> func(); //error
>
>
> Why?  The user should always have the option of ignoring error conditions, even to his own detriment.  Besides, with exceptions I could always do this:

The return value may not nessarily be an error condition (note that I'm not talking about exceptions here).

ie

checked int func() { }
int x = func(); //ok
func(); //error

int func() { }
int x = func(); //ok
func(); //ok

> try{ funcThatThrows(); }
> catch( ... ) {}
>
> 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.

Exactly, your just amplifying my point.  Exceptions are not good for flow of control (most of the time).

> Sean

Well it would still be possible to ignore (well type some extra code) it is just a kinda double check for cases where most of the time you need to check/use the value and where exceptions are not appropriate.

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