goto... Who uses it?
-
public static void SaveChartData(List dataList) { int totalDelays = 0; int value = 0; string errorString = ""; // Use a temporary file in case there are any parse errors. string tmpFilePath = applicationPath + "TmpChartData.csv"; using (StreamWriter sw = new StreamWriter(tmpFilePath)) { foreach (DataGridClass dgc in dataList) { if (!int.TryParse((dgc.MATL.Equals("") ? "0" : dgc.MATL), out value)) { errorString = dgc.MATL; goto ParseError; } totalDelays += value; if (!int.TryParse((dgc.EQUIP.Equals("") ? "0" : dgc.EQUIP), out value)) { errorString = dgc.EQUIP; goto ParseError; } totalDelays += value; if (!int.TryParse((dgc.People.Equals("") ? "0" : dgc.People), out value)) { errorString = dgc.People; goto ParseError; } totalDelays += value; if (!int.TryParse((dgc.Defects.Equals("") ? "0" : dgc.Defects), out value)) { errorString = dgc.Defects; goto ParseError; } totalDelays += value; if (!int.TryParse((dgc.Other.Equals("") ? "0" : dgc.Other), out value)) { errorString = dgc.Other; goto ParseError; } totalDelays += value; sw.WriteLine("{0},{1},{2},{3},{4},{5},{6},{7},{8},{9},{10}", dgc.Year, dgc.Month, dgc.Goal, dgc.Completions, totalDelays, dgc.to, dgc.MATL, dgc.EQUIP, dgc.People, dgc.Defects, dgc.Other); totalDelays = 0; value = 0; } } // If we got this far then there were no parse errors. File.Copy(tmpFilePath, chartData, true); return; ParseError: string msg = string.Format("Unable to parse data. Verify its entered correctly.\\r\\nValue = {0}", errorString); MessageBox.Sho -
Who uses it?
N00bs.
DanielSheets wrote:
It can make for cleaner code if used correctly.
Do you have an example? After years in the trade, I have still to see the first instance where it actually improves readability/maintainability.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Its all relative I suppose.
-
Eddy Vluggen wrote:
Do you have an example? After years in the trade, I have still to see the first instance where it actually improves readability/maintainability.
Hi, In C/C++ for e.g. in a switch statement where you must share some portion of code. Although one can put that shared part inside another function, for visibility & tracking purposes, some times is better to have the code in the same screen avoiding scrolling up and down to follow the code. Believe it, is real but I cannot show company code. I don't remember which old Pascal guru told that but sometimes a goto is preferable instead of doing a lot of work to avoid its usage and make the code difficult to read. For the other side, as an assembly programmer... I see JMPs everywhere hehehe. Regards, Mauro.
Mauro Leggieri wrote:
For the other side, as an assembly programmer... I see JMPs everywhere hehehe.
..simply because there's little alternative in assembly. Assumed we weren't talking about assembly, but higher-level languages - there are few people still working professionally with assembly.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
For what part? Why would I need to use exception handling when thats exactly what TryParse is used for (assuming thats what you're talking about)?
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
I've using one while I test some timeout code on a function, but I'll refactor it out before I commit it. Just nice to see the whole process at once for now (and I can make sure it works before I spend time figuring out exactly how to best cleanup before cancelling it).
-
public static void SaveChartData(List dataList) { int totalDelays = 0; int value = 0; string errorString = ""; // Use a temporary file in case there are any parse errors. string tmpFilePath = applicationPath + "TmpChartData.csv"; using (StreamWriter sw = new StreamWriter(tmpFilePath)) { foreach (DataGridClass dgc in dataList) { if (!int.TryParse((dgc.MATL.Equals("") ? "0" : dgc.MATL), out value)) { errorString = dgc.MATL; goto ParseError; } totalDelays += value; if (!int.TryParse((dgc.EQUIP.Equals("") ? "0" : dgc.EQUIP), out value)) { errorString = dgc.EQUIP; goto ParseError; } totalDelays += value; if (!int.TryParse((dgc.People.Equals("") ? "0" : dgc.People), out value)) { errorString = dgc.People; goto ParseError; } totalDelays += value; if (!int.TryParse((dgc.Defects.Equals("") ? "0" : dgc.Defects), out value)) { errorString = dgc.Defects; goto ParseError; } totalDelays += value; if (!int.TryParse((dgc.Other.Equals("") ? "0" : dgc.Other), out value)) { errorString = dgc.Other; goto ParseError; } totalDelays += value; sw.WriteLine("{0},{1},{2},{3},{4},{5},{6},{7},{8},{9},{10}", dgc.Year, dgc.Month, dgc.Goal, dgc.Completions, totalDelays, dgc.to, dgc.MATL, dgc.EQUIP, dgc.People, dgc.Defects, dgc.Other); totalDelays = 0; value = 0; } } // If we got this far then there were no parse errors. File.Copy(tmpFilePath, chartData, true); return; ParseError: string msg = string.Format("Unable to parse data. Verify its entered correctly.\\r\\nValue = {0}", errorString); MessageBox.ShoThat's horrible. Repeated code, and mixing of data management and UI code. It's crying out for throwing exceptions which you catch in the UI code, and a method
int parseNumericValue(String text){
int result;
if(!int.TryParse(text == "" ? "0" : text, out result))
throw new DataFormatException("Unable to parse data. Verify its entered correctly.\r\nValue = "+text);
return result;
}(and that's if the default exception from Parse doesn't do the job which it probably does). This is translated VB. And that's not a good thing.
-
In SQL - fairly often to jump to the error handler at the end of our sprocs. I'll admit there's no good reason we do this, since it's easy enough for us to avoid this with if statements, but it's a pattern used in our original code and so for consistency we stuck with it:
Create Procedure MyProc as
Begin Tran -- Do stuff... if @@error <> 0 goto errorHandler Commit Tran Return 0errorHandler:
Rollback Tran
Return 1cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
That's a pattern I have come across in Oracle PL/SQL and it does the job well. Of course one can use an if, as you mention, but if it is used judiciously it works well and does not break the logic any more than an else does.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
For what part? Why would I need to use exception handling when thats exactly what TryParse is used for (assuming thats what you're talking about)?
..on how to throw an exception. I wouldn't even expect the "if's", but rather a loop; and have each condition in a separate class.
using (StreamWriter sw = new StreamWriter(tmpFilePath)) { foreach (DataGridClass dgc in dataList) { foreach (var thingToTest in ParsesClasses) { Results.Add( thingToTest (dgc) ); }Wrap it in a try-catch, and done.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
I haven't used a "goto" since.....let's see now.....1995, in some assembly language I was writing for a graphics library. This s, if you call any flavor of JMP a "goto". Come to think of it, that's probably around the last time I've ever used the keyword "goto" in any higher languages.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
..on how to throw an exception. I wouldn't even expect the "if's", but rather a loop; and have each condition in a separate class.
using (StreamWriter sw = new StreamWriter(tmpFilePath)) { foreach (DataGridClass dgc in dataList) { foreach (var thingToTest in ParsesClasses) { Results.Add( thingToTest (dgc) ); }Wrap it in a try-catch, and done.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Thats swift. I'll be the first to admit that I dont have the experience or knowledge of 90% of the people here. Interesting.
-
In SQL - fairly often to jump to the error handler at the end of our sprocs. I'll admit there's no good reason we do this, since it's easy enough for us to avoid this with if statements, but it's a pattern used in our original code and so for consistency we stuck with it:
Create Procedure MyProc as
Begin Tran -- Do stuff... if @@error <> 0 goto errorHandler Commit Tran Return 0errorHandler:
Rollback Tran
Return 1cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Thats swift. I'll be the first to admit that I dont have the experience or knowledge of 90% of the people here. Interesting.
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
depends on the language. sometimes, there is no way to avoid it.
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
I have always thought goto was the equlivant of the assembly language jmp (blocking?), if it is I used one this morning. Goto is also acceptable in RTOS situations (which Windows isn't) if you want the valve to close now and not later. Glenn
-
His second stop was the bar, then other places and to write this post. I am assuming he is still enjoying the effects of the local bar. :)
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
-
In SQL - fairly often to jump to the error handler at the end of our sprocs. I'll admit there's no good reason we do this, since it's easy enough for us to avoid this with if statements, but it's a pattern used in our original code and so for consistency we stuck with it:
Create Procedure MyProc as
Begin Tran -- Do stuff... if @@error <> 0 goto errorHandler Commit Tran Return 0errorHandler:
Rollback Tran
Return 1cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
Real programmers (ones who code in languages like assembly, C and FORTRAN) use it all the time. Rest of us - rarely if ever.
-
This isn't a programming question. Anyway... I find it useful in very few situations. It can make for cleaner code if used correctly. Of course, it can also be over used.
Well as an assembly programmer I really don't have much choice. And as for higher level languages, sure, though rarely. There are people who religiously avoid it, but that's just silly. We must remember the reason it is seen as bad, and not open a witchhunt. Introducing a boolean variable just to quit out of a non-enclosing loop makes readability/understandability worse, not better, and refactoring an inner loop into its own function just so you can return out of it creates a bunch of tightly-coupled functions that do nothing useful on their own. Besides, that return would essentially be a goto.