How to read a file completely?
-
Is this in Java?
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
Nope, Java would have camelCase method names.
-
In some old code, I discovered following gem:
do { try { BDTLine line = new BDTLine(File); line.Read(); Lines.Add(line); } catch (Exception ex) { System.Diagnostics.Trace.WriteLine("Exception reading BDT file: "+ex.Message); break; } } while(true);The file seems to be read line by line, but actually
line.Read()reads a number of bytes. Some when the end of the file is reached, and it reads the next 7 bytes, an exception is thrown which is caught in the block above, which then stops further reading of the file; the error message nicely fills the log file. Great idea!I'm not really a .NET programmer, so I might be missing something here. I would expect this to break out of the do-while loop after the exception has been logged. So, if it breaks out of the infinite loop after writing to the log, why would it fill the log file? And surely it will only write to the log file if Trace is enabled? So in a production environment I wouldn't expect it to write anything at all. I'm not defending using infinite loops to process something that isn't endless like this, I think it's bad practice, but I don't understand why this would just keep writing error messages endlessly to the System Trace log, which is what the poster seems to suggest. As I said, I'm not a C# programmer really, so maybe there's something going on here I'm not aware of.
-
I'm not really a .NET programmer, so I might be missing something here. I would expect this to break out of the do-while loop after the exception has been logged. So, if it breaks out of the infinite loop after writing to the log, why would it fill the log file? And surely it will only write to the log file if Trace is enabled? So in a production environment I wouldn't expect it to write anything at all. I'm not defending using infinite loops to process something that isn't endless like this, I think it's bad practice, but I don't understand why this would just keep writing error messages endlessly to the System Trace log, which is what the poster seems to suggest. As I said, I'm not a C# programmer really, so maybe there's something going on here I'm not aware of.
you would be right if the while loop were inside the try block; as it is now, once something goes wrong the while loop keeps executing, causing ever more exceptions. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
you would be right if the while loop were inside the try block; as it is now, once something goes wrong the while loop keeps executing, causing ever more exceptions. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
So, if this is C#, the break takes you where? To find out, I tried this:
do
{
try
{
int a = 1;
int b = 0;
int c = a / b;
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
break;
}
} while (true);When the DivideByZeroException gets caught, it breaks out of the do-while loop, and does not keep showing the MessageBox over and over. Why is this different from the original example? I must be missing something obvious here.
-
So, if this is C#, the break takes you where? To find out, I tried this:
do
{
try
{
int a = 1;
int b = 0;
int c = a / b;
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
break;
}
} while (true);When the DivideByZeroException gets caught, it breaks out of the do-while loop, and does not keep showing the MessageBox over and over. Why is this different from the original example? I must be missing something obvious here.
You're right, the break prevents an eternal loop. Nevertheless the following is the normal way:
try
{
do
{
int a = 1;
int b = 0;
int c = a / b;
} while (true);
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
}as its structure better matches the intended operation, which is illustrated by the fact the break is not present anymore. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
You're right, the break prevents an eternal loop. Nevertheless the following is the normal way:
try
{
do
{
int a = 1;
int b = 0;
int c = a / b;
} while (true);
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
}as its structure better matches the intended operation, which is illustrated by the fact the break is not present anymore. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
Either way, it's a pretty sucky way to do things. I'm guessing that this is forced on the programmer because the BDTLine class is badly designed so the only choice is to continue to read until it throws an exception.
-
You're right, the break prevents an eternal loop. Nevertheless the following is the normal way:
try
{
do
{
int a = 1;
int b = 0;
int c = a / b;
} while (true);
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
}as its structure better matches the intended operation, which is illustrated by the fact the break is not present anymore. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
But why us
dowithwhile(true)? -
But why us
dowithwhile(true)?I wouldn't. When I need forever, I use
for(;;) {...}
and in C I would even
#define forever for(;;)
and yes I know I could do that in other C-like languages too using the/a pre-processor. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
I'm not really a .NET programmer, so I might be missing something here. I would expect this to break out of the do-while loop after the exception has been logged. So, if it breaks out of the infinite loop after writing to the log, why would it fill the log file? And surely it will only write to the log file if Trace is enabled? So in a production environment I wouldn't expect it to write anything at all. I'm not defending using infinite loops to process something that isn't endless like this, I think it's bad practice, but I don't understand why this would just keep writing error messages endlessly to the System Trace log, which is what the poster seems to suggest. As I said, I'm not a C# programmer really, so maybe there's something going on here I'm not aware of.
It breaks out of the loop with the first exception encountered, which is typically a System.IO.EndOfStreamException because the last line from which is read is always empty. And the normal way to leave that loop is exactly this exception. Every file read will cause three such lines in the log file (later on, the file is read another two times - it is certain that it has not changed between reads...). The next file causing another three lines in the log, and so on. When searching for the cause of a different error I was severely mislead by these messages.
-
In some old code, I discovered following gem:
do { try { BDTLine line = new BDTLine(File); line.Read(); Lines.Add(line); } catch (Exception ex) { System.Diagnostics.Trace.WriteLine("Exception reading BDT file: "+ex.Message); break; } } while(true);The file seems to be read line by line, but actually
line.Read()reads a number of bytes. Some when the end of the file is reached, and it reads the next 7 bytes, an exception is thrown which is caught in the block above, which then stops further reading of the file; the error message nicely fills the log file. Great idea! -
In some old code, I discovered following gem:
do { try { BDTLine line = new BDTLine(File); line.Read(); Lines.Add(line); } catch (Exception ex) { System.Diagnostics.Trace.WriteLine("Exception reading BDT file: "+ex.Message); break; } } while(true);The file seems to be read line by line, but actually
line.Read()reads a number of bytes. Some when the end of the file is reached, and it reads the next 7 bytes, an exception is thrown which is caught in the block above, which then stops further reading of the file; the error message nicely fills the log file. Great idea!Simply bad design and very poor naming conventions. 1) Call things what they are, nothing more, nothing less. Class BDTLine should be BDTFile line should be lines .Read method should be .ReadLine (or should it be ReadBytes?) Now when you look at the code you can see why it is loaded with problems. 2) BDTFile is an implementation nightmare for you or anyone else in the future. 2a) If the caller manages the loop, the class must expose a property to determine when to stop.
public bool EOF { get { return sr.Peek > -1; } // StreamReader } _eof=((input=sr.ReadLine())==null) get { return _eof; } // FileReader2b) if the class manages the loop, either pass the lines reference or return the desired result from the Read method. 3) Finally there is no excuse for using do...while(true), period.Dwayne J. Baldwin
-
In some old code, I discovered following gem:
do { try { BDTLine line = new BDTLine(File); line.Read(); Lines.Add(line); } catch (Exception ex) { System.Diagnostics.Trace.WriteLine("Exception reading BDT file: "+ex.Message); break; } } while(true);The file seems to be read line by line, but actually
line.Read()reads a number of bytes. Some when the end of the file is reached, and it reads the next 7 bytes, an exception is thrown which is caught in the block above, which then stops further reading of the file; the error message nicely fills the log file. Great idea!Maybe it's just me, but using code that could cause an exception would mean that I'd rewrite it to not cause an exception. Why wouldn't you just do something like:
try
{
StreamReader sr = new StreamReader("TestFile.txt");
string data = sr.ReadToEnd();
string[] lines = data.Split(Environment.NewLine.ToCharArray());
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
} -
you would be right if the while loop were inside the try block; as it is now, once something goes wrong the while loop keeps executing, causing ever more exceptions. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
Loop should exit on first exception if there is no try block. I agree with you in this case it wouldn't stop excuting as it has a catch block. But I wonder if it will ever throw end of file exception? as everytime a new Object is created against physical file that would start reading file from start so there would be no end of file ever. but it could throw infinite loop exception though? Your thoughts?
**
R A M
**
-
Loop should exit on first exception if there is no try block. I agree with you in this case it wouldn't stop excuting as it has a catch block. But I wonder if it will ever throw end of file exception? as everytime a new Object is created against physical file that would start reading file from start so there would be no end of file ever. but it could throw infinite loop exception though? Your thoughts?
**
R A M
**
You missed the
breakin the catch block. And so did I initially. It is ugly; if the goal is to leave the loop on exceptions, then the loop should sit inside the try block, not the other way around. :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
You missed the
breakin the catch block. And so did I initially. It is ugly; if the goal is to leave the loop on exceptions, then the loop should sit inside the try block, not the other way around. :)Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
I understand.. but my point is will that read anything after first line as Object to read file is initiated EVERYTIME in loop
**
R A M
**
-
I understand.. but my point is will that read anything after first line as Object to read file is initiated EVERYTIME in loop
**
R A M
**
I can't tell from what is shown. Is file a string, and BDTline opening said file? or is file some kind of object (say a StreamReader), that has the file opened earlier on, and parses/returns a single line? :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.