Использование Goto для улучшения принципа DRY и четкости кода: хорошая идея?

Question

У меня есть некоторый код, который структурирован как следующее:

if (someStatement) 
{ 
    //... 
    if (SomeOtherStatement) 
    { 
     //..., possibly more cases like this 
    } 
    else 
    { 
     //goto warning; 
     //would otherwise repeat 
     //the MessageBox.Show here 
    } 
} 
else 
{ 
    //goto warning; 
} 
//... 
warning: 
MessageBox.Show("some warning"); 

Как я отрекаюсь копированием кода, это один из немногих полезных применений Готы или есть лучше структура я могу использовать?

Answer 1

Как насчет этого?

if (someStatement) 
{ 
    //... 
    if (SomeOtherStatement) 
    { 
     //..., possibly more cases like this 

     return; // in the inner-most case 
    } 
} 

MessageBox.Show("some warning"); 

Answer 2

Я лично считаю централизованное управление ошибками «почти единственным случаем», где goto является приемлемым. Однако для лучшей структуры я бы поставил ярлык полностью вне другого, в самом конце вашей функции.

Answer 3

Вы видите одно и то же сообщение об ошибке на обеих линиях? Затем вы должны написать функцию, которая вызывает только эту строку, и вызывать эту функцию в обоих случаях.

if (someStatement) 
{ 
    //... 
    if (SomeOtherStatement) 
    { 
     //..., possibly more cases like this 
    } 
    else 
    { 
     showError(); 
    } 
} 
else 
{ 
    showError(); 
} 

ОТВЕТ: Это плохой пример, его можно решить с помощью одной ветви else, улавливающей ошибку. Вот лучше один:

if (!doSomething()) 
{ 
    showError(); 
} 
doSomethingElse(); 
if (!anotherCall()) 
{ 
    showError(); 
} 

Answer 4

Да, но только если по goto вы имеете в виду «создать функцию и вызвать ее несколько раз».

Answer 5

лучший подход зависит от того, как выглядит остальная часть вашего кода. если код показан последний код в этом методе:

if(someStatement) { 
    // ... 
    if(SomeOtherStatement) 
    { 
     // a couple of lines of code 
     return; // ! 
    } 
} 

MessageBox.Show("someWarning"); 

, если нет, то вы, вероятно, придется возразить что-то вроде этого:

if(someStatement) { 
    // ... 
    if(SomeOtherStatement) 
    { 
     // a couple of lines of code 
    } 
    else 
    { 
     showWarning("not someOtherStatement"); 
    } 
} 
else 
{ 
    showWarning("not someStatement"); 
} 

Answer 6

Исключением являются правильный способ обработки ошибок в .NET , выбросить их, но и использовать их с умом:

try 
{ 
    if (someStatement) 
    { 
     //... 
     if (SomeOtherStatement) 
     { 
      //..., possibly more cases like this 
     } 
     else 
     { 
      throw new MyException(); 
      //would otherwise repeat 
      //the MessageBox.Show here 
     } 
    } 
} 
catch(MyException e) 
{ 
    MessageBox.Show(e.Message); 
    // log the exception, if necessary 
} 
finally 
{ 
    // tidy up 
} 

за исключением вы получаете сильно типизированный ответ на то, что пошло не так, которые вы можете легко реализовать в системы регистрации.

Answer 7

Если вы собираетесь вступить в глубокую неприятную инструкцию по тестированию ошибок, как и у вас, то вам может потребоваться обернуть ее с помощью одного try/catch и выбросить соответствующие исключения для конкретного приложения из инструкции if. поймать те конкретные исключения в блоке catch, позволяя всем остальным поймать дальше цепочку.

Answer 8

Поскольку (начиная с FrameWork 1.1) логический и «& &«: »оценивает только свой второй операнд, если необходимо».

Что случилось с:

if(someStatement && someOtherStatement) 
{ 
     // more whatever 
} 
else 
{ 
     // raise an exception, call a method, show messagebox, whatever 
} 

В зависимости от сложности логической оценки происходит, если первое условие вычисляется как истина: и вы, возможно, реализовать множество других тестов, любое число которых может привести к в ошибках: все из которых вы хотите обрабатывать одинаковым образом: я бы счел обязательным либо поднять конкретное исключение, вызвать метод для обработки ошибки, либо поместить все это в блок try-catch (который может быть довольно уродливым, если есть много кода).

Метод с низким уровнем заглушки, который я использовал бы, если бы разумная презумпция того, что вероятность ошибки была довольно удаленной в 99% случаев, когда был вызван код: я бы установил булевский флаг, чтобы отразить состояние ошибки: оцените его при завершении сложного блока кода и сделайте то, что нужно сделать: конечно , если ваш код отлучается где-то в результате этих внутренних оценок: это не будет хорошо.

Answer 9

Я думаю, что goto - плохая идея. Если вам нужно прыгать, бросьте исключение, как было предложено joshcomley; если вы просто хотите вывести предупреждающее сообщение, но продолжайте без прыжка, вызовите метод.