|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
But why us do with while(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.
|
|
|
|
|
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 break in 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.
|
|
|
|
|
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?
|
|
|
|
|
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.
|
|
|
|
|
This looks bad pratice to me, to break loop on exception, rather then actually detecting and comparing EOF character.
Ravi S
Coding is my birth-right and bugs are part of feature my code has!
_________________________________________
Me
Facebook
Twitter
|
|
|
|
|
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.
<br />
public bool EOF { <br />
get { return sr.Peek > -1; }
}<br />
<br />
_eof=((input=sr.ReadLine())==null)<br />
get { return _eof; }
2b) 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
|
|
|
|
|
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);
}
|
|
|
|
|
A couple of years back I had a chap working in my team who knew various .Net specifics but didn't really seem to understand programming at all. He produced various pieces of "interesting" code but this was his finest hour:
bool moreThanOneModelTypes = (vehicle.PossibleTypes.Length > 1);
switch (moreThanOneModelTypes)
{
case true:
this.ddlVehicleFullModelType.Items.Add(new ListItem("- - - please select - - -", "-1"));
goto default;
case false:
goto default;
default:
foreach (VehicleType vehicleType in vehicle.PossibleTypes)
{
this.ddlVehicleFullModelType.Items.Add(new ListItem(vehicleType.DisplayName, vehicleType.Id));
}
_fullVehicleModelTypeReload = false;
break;
}
So that's a single-line if statement replaced with a multi-line switch, plus some gotos for good measure all because he got bored of if..else.
|
|
|
|
|
The default in this is surely a marsterwork par excellance. I must have been misinformed, boolean=true|false|maybe.
ragnaroknrol The Internet is For Porn[^]
Pete o'Hanlon: If it wasn't insulting tools, I'd say you were dumber than a bag of spanners.
|
|
|
|
|
You should applaud the genius for holding into account quantum mechanics!
|
|
|
|
|
|
Is this guy in his 50's, bald, close-set eyes? If it is, I used to work with him :shudder:.
|
|
|
|
|
one half of me is LMAO, the other half is straight faced and the rest is thinking if that can be incorporated in my own code.
...byte till it megahertz...
|
|
|
|
|
LOL @ three halves
Before .NET 4.0,
object Universe = NULL;
|
|
|
|
|
I have to ask - was there ever a case in which the default clause executed? Did the author honestly expect it to?
Bear in mind that Boole's wife was also a mathematician, and in her algebra there were three states: "true", "false", and "it depends..."
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Just found 
Is it GPLed ?
Can I use this portion of code? 
|
|
|
|
|
While that code snippet may indeed produce the desired effect it is one of the most convoluted ways I have seen of doing a simple task. See my sig.
You should tell that guy about the International Obfuscated C Code Contest (IOCCC[^])
Just because the code works, it doesn't mean that it is good code.
modified on Wednesday, August 25, 2010 2:40 PM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
