Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 


 
     
Recent Posts
   
Popular Topics
Home   
Search
    Members    Calendar    Who's On

Home » SQLServerCentral.com » Editorials » GOTO and T-SQL
Add to briefcase
21 posts, Page 2 of 3
««123»»

GOTO and T-SQL Expand / Collapse
Rate Topic
Display Mode
Topic Options
Author
Message
batesview
Posted Thursday, December 22, 2011 5:51 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: 2 days ago @ 4:13 AM
Points: 10, Visits: 171
Got to agree with the general point of Phil's editorial. Look at the instruction set of even the most up to date Processors and they all still include a GOTO and or JUMP statement. Sometimes there is just not a better way to skip some statements. In T-SQL oddly I've never needed GOTO but the day may come and I'm glad its still there.
Post #1225751
Ian Massi
Posted Thursday, December 22, 2011 6:46 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Friday, May 17, 2013 11:53 AM
Points: 1,303, Visits: 1,661
First assignment in university I used GOTO.
It came back with red ink saying not to.
I cried and I wailed.
Then realized it was I who had failed.
Then I bid GOTO adieu.
Post #1225786
Simon Facer
Posted Thursday, December 22, 2011 7:07 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, May 16, 2013 7:30 AM
Points: 1,566, Visits: 600
I've been coding for 25+ years, starting out in COBOL on IBM mainframes. GOTOs when used wisely can provide an invaluable coding construct. It all comes down to the 'style' of the coder - if they use GOTO carefully and with structure, it can really simplify a code module. But, unfortunately, most people just abuse it, and they (rightly so) get told not to do that again.
Like a lot of options, use it wisely, because if you abuse it, it will bite you.

And, YES, I do still code with GOTOs in T-SQL, where appropriate.

Post #1225794
GSquared
Posted Thursday, December 22, 2011 7:11 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Monday, May 06, 2013 1:09 PM
Points: 15,439, Visits: 9,569
I'd use a GOTO if I felt the need. Mostly though, the "Not-a-GOTO" statements handle it these days. So I haven't used a literal "GOTO" in T-SQL in years.

After all, "While Begin End" is just a goto loop, with "End" instead of "Goto" and "While" instead of a target label. Same can be said for Try Catch being a "covert GOTO".

Different name, same mechanism, same use, better rep.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #1225799
Eric M Russell
Posted Thursday, December 22, 2011 7:48 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Today @ 2:02 PM
Points: 1,162, Visits: 3,333
In addition to making the code less structured and less readable, another problem (at least for those who choose to use it) with T-SQL's implementation of GOTO is that it's less functional; it's a one way jump and there is no equivalent to Visual Basic's RETURN statement to return control to the statement after the one that issued the GOTO. We do have a RETURN statement, but it's not used for returning from a GOTO branch. That limited control flow functionality was actually good, it prevented T-SQL developers from ever making extensive usage of the GOTO. I don't think I've ever worked in an organization where it's use was common, except for error handling in v2000 and earlier.

I use bit flag variables for control flow extensively, and I may even have a half dozen or more for a procedure with a complex braching process, because the same indicator may control multiple code blocks, and that reusability makes the code more readable. For example:

if @use_old_elig_table = 1
begin
...
end;

Sometimes I'll even expose the indicator flags as output parameters, so they can be used for unit testing purposes, or so the application can use them to determine details about what steps were performed internally by the stored procedure.

"Wise people understand the 10,000 things without going to each one.
They know them without having to look at each one,
and they transform all without acting on each one." - The Tao Te Ching: Verse 47
Post #1225817
Randy Rabin
Posted Thursday, December 22, 2011 10:59 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Monday, April 15, 2013 10:41 AM
Points: 498, Visits: 508
no equivalent to Visual Basic's RETURN statement to return control to the statement after the one that issued the GOTO


I think you're actually thinking of the GOSUB statement, which we have in T-SQL as EXEC.

While I haven't personally used GOTO in a very long time either, I can still see a restricted use for it, for the purpose of jumping forward in code (but never backward). Just my 2c but I don't always want every stored proc I write to be one huge TRY..CATCH block.

I find it interesting that Microsoft themselves still use GOTO (2008 R2 at least, haven't tried 2012) when scripting out a SQL Agent job from SSMS.


Post #1225926
Revenant
Posted Thursday, December 22, 2011 11:13 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 10:44 AM
Points: 3,452, Visits: 2,527
GOTO is not as evil as it is painted today. When Dijkstra wrote his paper - which not many today's programmers have read -, real programmers programmed in Assembler and GOTO was one of the flavors of the 'branch' instruction. The recommended error handling construct looked like this:

* coming back from a Supervisor call; return code is in register 1
* return codes were multiples of 4
         B     *+4(1)   *+4 is the address of the following instruction
         B     success   you get here if the return code was 0
         B     error4     you get here if the return code was 4
         B     error8     etc.

Imagine debugging a program with several 'branch tables' like this. Some Supervisor calls might return over 20 different errors.

On the other hand, some GOTOs were actually encouraged; e.g., BXLE or Branch on Index Lower or Equal, which was the best way to do a WHILE loop.
Post #1225933
pdanes
Posted Thursday, December 22, 2011 3:48 PM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Today @ 4:36 AM
Points: 257, Visits: 690
Blanket prohibitions are generally a bad idea in any field. All processors have Jump instructions, which are low-level GOTOs, and high-level languages compile or interpret down to that, so your actual code is full of GOTOs anyway, now matter how fanatic you are about structure. They're like any tool - they can be misused, and they can be the best tool for the job. People who automatically just repeat the 'GOTO is BAD' mantra are sheep - I prefer to think for myself.

I also wish T-SQL had a GoSub statement - would have been perfect for a job just today. Instead, I wound up with a couple of GOTOs and some awkward tests.
Post #1226036
David.Poole
Posted Thursday, December 22, 2011 4:36 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 12:46 PM
Points: 2,749, Visits: 1,406
A lot of ideas that are painted black are due to mis-interpretations.

Take Hungarian notation. Simonyi suggested its use to signal intent but people mis-interpretted this to signify type. Thats why we get tables beginning with tbl; due to that mis-interpretation.

You could argue that SQL2005/2008 schemas and namespaces are actually closer to expressing Simonyi's original idea.

LinkedIn Profile
Post #1226041
IceDread
Posted Thursday, December 22, 2011 5:10 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, November 16, 2012 3:47 AM
Points: 290, Visits: 988
Revenant (12/22/2011)
GOTO is not as evil as it is painted today. When Dijkstra wrote his paper - which not many today's programmers have read -, real programmers programmed in Assembler and GOTO was one of the flavors of the 'branch' instruction. The recommended error handling construct looked like this:

* coming back from a Supervisor call; return code is in register 1
* return codes were multiples of 4
         B     *+4(1)   *+4 is the address of the following instruction
         B     success   you get here if the return code was 0
         B     error4     you get here if the return code was 4
         B     error8     etc.

Imagine debugging a program with several 'branch tables' like this. Some Supervisor calls might return over 20 different errors.

On the other hand, some GOTOs were actually encouraged; e.g., BXLE or Branch on Index Lower or Equal, which was the best way to do a WHILE loop.


Don't tell me your one of those that thinks assembler is real programing? I bet you don't from the way you write! Thou it's not entirely uncommon. Those goofs that likes to invent the wheel all over again and again..

No I still stand by that GOTOs in 99% of all cases are written because the programmer did not know better and that was how he did it 20 years ago.
Post #1226049
« Prev Topic | Next Topic »

Add to briefcase
21 posts, Page 2 of 3
««123»»

Permissions Expand / Collapse

 
 
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.