how to determine whether stream is open or closed

[Madhur Ahuja]

Hello

I have created a wrapper class for reading and writing objects
in my application. The functions of this class are mainly to
provide ObjectInputStream and ObjectOutputStream objects
to the caller.

The problem I am facing is in close function. How do I ensure
that stream I am closing is really open. Should I just blindly
call ObjectInputStream.close(), even though the stream might
be already closed.

class MyFile
{
private FileInputStream fis;
private FileOutputStream fos;
private ObjectInputStream ois;
private ObjectOutputStream oos;
private String filename;
public BufferedInputStream br;

MyFile(String filename)
{
this.filename=filename;
File ff =new File(filename);
if(ff.exists())
;
else
{
try
{

FileOutputStream fis=new FileOutputStream(filename);
fis.close();
}
catch(Exception e)
{
e.printStackTrace();
}
}


}

public void close()
{

file://if(fis.)
file://fis.close();
file://if(fis.available())
// fos.close();


}

public ObjectInputStream getReader()
{
try
{

fis=new FileInputStream(filename);
file://br=new BufferedInputStream(new FileInputStream());
br=new BufferedInputStream(fis);
ois=new ObjectInputStream(br);
return ois;

}
catch(EOFException e)
{
file://e.printStackTrace();
System.out.println("eof");
return null;
}
catch(Exception e)
{
e.printStackTrace();
return null;
}



}

public ObjectOutputStream getWriter()
{
File ff =new File(filename);
try
{

if(ff.exists())
{
fos=new FileOutputStream(filename,true);
}
else
{
fos=new FileOutputStream(filename);
file://fis.close();
}
}
catch(Exception e)
{
e.printStackTrace();
return null;
}

file://br=new BufferedInputStream(new FileInputStream());
try
{
oos=new ObjectOutputStream(fos);
}
catch(Exception e)
{
e.printStackTrace();
}
return oos;
}
}

 

[Gordon Beaton]

The problem I am facing is in close function. How do I ensure that
stream I am closing is really open. Should I just blindly call
ObjectInputStream.close(), even though the stream might be already
closed.

If you want to close the stream, just call close(). Are you worried
that something bad will happen if it was already closed?

public ObjectInputStream getReader()

BTW your use of the terms "Reader" and "Writer" is confusing, since
Readers and Writers in Java are typically used to handle character
data (i.e. plain text), not binary data or serialized Objects. I'd
suggest names like "getObjectInputStream" and "getObjectOutputStream"
instead.

/gordon

 

[Madhur Ahuja]

If you want to close the stream, just call close(). Are you worried
that something bad will happen if it was already closed?

No. But I think it will be waste of CPU cycles to close the already
closed stream.

BTW your use of the terms "Reader" and "Writer" is confusing, since
Readers and Writers in Java are typically used to handle character
data (i.e. plain text), not binary data or serialized Objects. I'd
suggest names like "getObjectInputStream" and "getObjectOutputStream"
instead.

You are right. Ill correct that one.

 

[andreas]

No. But I think it will be waste of CPU cycles to close the already
closed stream.

are you calling the close() in some inner loop??
if not, i don't think the cpu cycles used to close() have any revelance on
the speed of your program. if i recall right, a socket under unix is a
filedescriptor
which just will be deallocated on close(). hence, it uses few cycles only
and
can easily be ingored compared to i/o to disk.

also, i assume testing for the socket to be open (i.e. finding its
filedescriptor in
the "open files" table of the process) takes about as much cycles as
close().

andreas

 

[Madhur Ahuja]

are you calling the close() in some inner loop??

loop? loop for what?
Its a function which is defined like this:
See my original post for complete class
public void close()
{
try
{

if(ois!=null) ois.close();
if(oos!=null) oos.close();
}
catch(Exception e)
{
e.printStackTrace();

}
}

if not, i don't think the cpu cycles used to close() have any
revelance on the speed of your program. if i recall right, a socket
under unix is a filedescriptor
which just will be deallocated on close(). hence, it uses few cycles
only and
can easily be ingored compared to i/o to disk.

Thanks for the info. Since I am using Windows, Is this applies to Windows
also.
What I have noticed that, if I dont close the stream in the application, I
cannot
delete or rename the file during the execution of that application.