Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #21720 > unrolled thread

Reading a File

Back to article view | Back to comp.lang.java.programmer

Contents

  Reading a File Subhabrata <subhabangalore@gmail.com> - 2013-01-25 20:58 -0800
    Re: Reading a File Knute Johnson <nospam@knutejohnson.com> - 2013-01-25 21:33 -0800
      Re: Reading a File subhabangalore@gmail.com - 2013-01-25 21:53 -0800
        Re: Reading a File Lew <lewbloch@gmail.com> - 2013-01-25 22:48 -0800
          Re: Reading a File Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-01-26 08:01 -0400
            Re: Reading a File Lew <lewbloch@gmail.com> - 2013-01-26 10:12 -0800
            Re: Reading a File Knute Johnson <nospam@knutejohnson.com> - 2013-01-26 11:41 -0800
              Re: Reading a File Lew <lewbloch@gmail.com> - 2013-01-26 13:01 -0800
    Re: Reading a File Roedy Green <see_website@mindprod.com.invalid> - 2013-01-26 02:47 -0800

#21720 — Reading a File

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.

[toc] | [next] | [standalone]

#21722

On 1/25/2013 8:58 PM, Subhabrata wrote:
> 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.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#21723

Thank you Sir. It worked. Regards,Subhabrata. 

[toc] | [prev] | [next] | [standalone]

#21726

subhaba...@... wrote:
> Thank you Sir. It worked. Regards,Subhabrata.

Actually, no, it didn't, but the bugs are of a nature that doesn't bother you yet.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#21735

On 01/26/2013 02:48 AM, Lew wrote:
> subhaba...@... wrote:
>> Thank you Sir. It worked. Regards,Subhabrata.
>
> 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

[toc] | [prev] | [next] | [standalone]

#21741

Arved Sandstrom wrote:
> Lew wrote:
>> subhaba...@... wrote:
>>> Thank you Sir. It worked. Regards,Subhabrata.
> 
>> 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.

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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#21746

On 1/26/2013 4:01 AM, Arved Sandstrom wrote:
> On 01/26/2013 02:48 AM, Lew wrote:
>> subhaba...@... wrote:
>>> Thank you Sir. It worked. Regards,Subhabrata.
>>
>> Actually, no, it didn't, but the bugs are of a nature that doesn't
>> bother you yet.

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.

-- 

Knute Johnson

[toc] | [prev] | [next] | [standalone]

#21749

On Saturday, January 26, 2013 11:41:00 AM UTC-8, Knute Johnson wrote:
> That's all I have to say about that.

All of which was fully addressed before your post.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#21729

On Fri, 25 Jan 2013 20:58:06 -0800 (PST), Subhabrata
<subhabangalore@gmail.com> wrote, quoted or indirectly quoted someone
who said :

>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 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web