В каком случае допустимо использование оператора T-SQL GOTO?

В «религиозной» дискуссии о форматировании кода Microsoft T-SQL я спросил, доступна ли инструкция GOTO в синтаксисе T-SQL. За 13 лет использования T-SQL мне ни разу не приходилось его использовать, да я и не знал, существует ли он. После краткого поиска документации, к моему ужасу, она действительно существует!

Мой вопрос таков:

Есть ли по крайней мере один случай, когда операторы GOTO дадут решение, которое работает лучше, чем решение, в котором используются другие программные конструкции более высокого порядка?

  • Реализация алгоритма шифрования

Мой вопрос НЕ:

  • Как использовать небольшие функциональные возможности, не создавая для этого целую функцию?
  • Как воспроизвести функциональность обработки ошибок без копирования/вставки?

sql tsql coding-style goto
person Norman H    schedule 26.07.2013    source источник
comment
Однажды я решил вопрос, где нужен переход: stackoverflow.com/questions/7244617/   -  person t-clausen.dk    schedule 26.07.2013
comment
@ t-clausen.dk Это определенно нужно указать в качестве ответа! Конечно, это интересное и уникальное использование GOTO! Любые мысли о том, почему вы не использовали цикл while?   -  person Norman H    schedule 26.07.2013
comment
это можно было бы сделать и с WHILE :)   -  person Nenad Zivkovic    schedule 26.07.2013

Ответы (3)


arrow_upward
5
arrow_downward

Я почти никогда не использую GOTO и легко могу обойтись без него.

Единственный случай, когда я бы рассмотрел его использование, - это когда у меня сложный код, который выполняет много проверок ошибок. Я мог бы предпринять некоторые действия, когда ошибка возвращается, и GOTO позволяет мне определить один блок кода для проверки ошибок.

Вы можете решить эту проблему несколькими способами, но GOTO является разумным вариантом, который гарантирует, что ошибки обрабатываются последовательно, а код не загроможден множеством операторов if @Error = 0 . . ..

person Gordon Linoff    schedule 26.07.2013
comment
Я предполагаю, что здесь вы имеете в виду катастрофическую обработку ошибок для таких вещей, как 5 операторов, которые могут завершиться ошибкой, и если какой-либо из них не работает, просто используйте один блок обработки ошибок. - person Norman H; 29.07.2013
comment
Похоже, что теперь этой ситуации в основном можно избежать благодаря семантике try-catch, доступной в более новых версиях SQL Server. @ Гордон Линофф, ты сравнил два метода? - person Norman H; 18.09.2013
comment
@НорманХ. . . Блоки try/catch не заменяют GOTO и обработку ошибок. Код обработки ошибок, по сути, является кодом выхода для хранимой процедуры, скажем, для регистрации ошибок при их обнаружении. Блок try/catch перехватывает ошибку (и может ее обработать, но смысл общего кода обработки ошибок заключается в том, чтобы избежать многократного повторения одного и того же кода). - person Gordon Linoff; 18.09.2013

arrow_upward
2
arrow_downward

я несколько раз видел goto в больших сценариях, где люди использовали его для улучшения читабельности. иногда он лучше читается, но чаще всего превращается в спагетти-код.

я вижу только одну ситуацию, когда goto может работать лучше. это внутри многократного цикла while. вы можете использовать goto один раз вместо нескольких breaks, которые просто существуют в самом внутреннем цикле . тем не менее, на мой взгляд, break не намного лучше, чем goto, это не очень хороший стиль программирования.

while ...
  while ...
    while... 
    break
  break
break


while ...
  while ...
    while... 
    goto endloops

endloops:
person Koryu    schedule 26.07.2013
comment
Это отличный ответ и уникальный подход. Конечно, защита от спагетти-кода является сложной задачей, но это может произойти даже при полном использовании функций! - person Norman H; 26.07.2013

arrow_upward
0
arrow_downward

Я использовал операторы GOTO в основном, когда служба SSIS была недоступна (не спрашивайте!!), чтобы обеспечить некоторый поток управления для большой хранимой процедуры, используемой для обработки ETL. Это единственный раз, когда я когда-либо использовал их, и, хотя они полезны в этом сценарии, это явно не тот сценарий, в котором вы оказались бы.

person Mark P    schedule 14.05.2018