Reading a File

S

Subhabrata

Dear Group,

I am a new learner in Java. And I wanted to open a file and read its
content.
The standard tutorials give long code. They use try,catch etc. I
wanted something simple and started to experiment something as
follows. But it was giving some error.

import java.io.*;
public class FileOutput {

/**
* @param args
*/
public static void main(String[] args) {
FileInputStream fstream = new FileInputStream("C:\\FileIO\
\javadict.txt");
DataInputStream in = new DataInputStream(fstream);
BufferedReader br = new BufferedReader(new InputStreamReader(in));
String strLine;
System.out.println(br.strLine);
}

// TODO Auto-generated method stub

}

If any one in the room can kindly suggest.

Regards,
Subhabrata.
NB: Thank you all for your earlier solution though I worked my own
with .equals only.
 
K

Knute Johnson

Dear Group,

I am a new learner in Java. And I wanted to open a file and read its
content.
The standard tutorials give long code. They use try,catch etc. I
wanted something simple and started to experiment something as
follows. But it was giving some error.

import java.io.*;
public class FileOutput {

/**
* @param args
*/
public static void main(String[] args) {
FileInputStream fstream = new FileInputStream("C:\\FileIO\
\javadict.txt");
DataInputStream in = new DataInputStream(fstream);
BufferedReader br = new BufferedReader(new InputStreamReader(in));
String strLine;
System.out.println(br.strLine);
}

// TODO Auto-generated method stub

}

If any one in the room can kindly suggest.

Regards,
Subhabrata.
NB: Thank you all for your earlier solution though I worked my own
with .equals only.

import java.io.*;

public class ReadIt {
public static void main(String[] args) throws IOException {
FileReader fr = new FileReader("ReadIt.java");
BufferedReader br = new BufferedReader(fr);

String str;
while ((str = br.readLine()) != null)
System.out.println(str);

br.close();
}
}

You will need to catch exceptions in real code but this will work unless
an exception is thrown.
 
R

Roedy Green

I am a new learner in Java. And I wanted to open a file and read its
content.
The standard tutorials give long code. They use try,catch etc. I
wanted something simple and started to experiment something as
follows. But it was giving some error.

see http://mindprod.com/applet/fileio.html

The catch is Java I/O is verbose. It works like a Lego set. Use my
applet to generate code and copy paste.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law
 
A

Arved Sandstrom

Actually, no, it didn't, but the bugs are of a nature that doesn't bother you yet.
Depends on how you run it as to whether that filename actually locates
the source file.

Overall the program itself "works". main() throws an exception, which
may be acceptable for a console app. Hardcoding the filename isn't a
defect unless you have a requirement to specify variable files.

Having it in the default package ain't great, along with not using
braces for the loop I'd nominate this as a latent defect.

AHS
 
L

Lew

Arved said:
Depends on how you run it as to whether that filename actually locates
the source file.

Overall the program itself "works". main() throws an exception, which
may be acceptable for a console app. Hardcoding the filename isn't a
defect unless you have a requirement to specify variable files.

Having it in the default package ain't great, along with not using
braces for the loop I'd nominate this as a latent defect.

Excellent code review, Arved.

Gentle Reader, the purpose of code is to do a certain job. For the OP's purpose,
the program worked. As weeds are merely plants for which one doesn't have a use yet,
so working code comprises bugs for which one doesn't have a scenario yet.

So the program works because we don't yet care about bugs like "the error message on
the console is ugly" because we don't care that it's ugly until we put the program in front
of a different audience.

Ontologically is that a bug? Who cares? It only matters that it doesn't have bugs that we
care about now - however loosely we define terms.

Or do we care? Certain observations show increased likelihood that program features will
function as bugs and that this will bother us eventually, compared to a near-horizon
analysis. Namely, source code is more viral than naive expectations allow - that 'throws
IOException' will be seen as ugly by important people within the code's lifetime, like as not.
Bad habits ingrain - it becomes increasingly hard to write graceful error handling the less you
practice it. People model their practices after bad examples. Vital knowledge is missed early
in the learning process - by the time you're getting a paycheck for it, it's late to learn for
the first time how packages reduce emergent bugs.

Best practices are best practices because they deal with the far horizon - you and your code
have an impact farther in time and space than some realize. It's not over-engineering to fully
Javadoc your code, to handle all sorts of weird inputs, to log errors (using *logging*), to gracefully
absorb errors and convert them back to stable program state, to follow naming and indentation
conventions, to properly factor your code into modules and packages, to use type-safe idioms,
or to fully understand the idioms and libraries available. Not even as a beginner or in prototype
code.

Arved's code review points to the balances in the proffered code and delineates the boundaries
where its behavior begins to be describable as buggy. This is engineering - you make tradeoffs
based on the real needs of the moment without forgetting the limitations you're causing yourself.
 
K

Knute Johnson

How has it failed? Sub seems to think it does the job he requires.
Depends on how you run it as to whether that filename actually locates
the source file.

There was no requirement or intent to 'locate' the source file.
Overall the program itself "works". main() throws an exception, which
may be acceptable for a console app. Hardcoding the filename isn't a
defect unless you have a requirement to specify variable files.

There was no requirement for a GUI program. There was no requirement to
specify the file name.
Having it in the default package ain't great, along with not using
braces for the loop I'd nominate this as a latent defect.

AHS

Being in the default package doesn't change its functionality or fail to
meet any of Sub's requirements. Adding unnecessary braces, while
currently in vogue, does not change the program's functionality either
and may in fact make it more complicated for Sub to understand.

His requirements were, no try/catch blocks and simple. The code I
provided meets Sub's requirements and "It worked." Not only that I
simplified his code example by removing the FileInputStream and the
DataInputStream.

What you didn't mention is that there is no way to use anything but the
default character set. Heavens, how could you have forgotten that!

Clearly this is not a program Sub is going to use for anything except a
place to start learning how to do simple I/O. He has a long way to go
and rather than critiquing my assistance you should have provided him a
good example Arved. If you want to contribute, give your competence to
Sub, that's what you should be here to do anyway.

That's all I have to say about that.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top