Каково преимущество - в то время как (ложь)?
Высвобождение средств должно быть "безопасной" операцией - в конце концов, как я могу восстановиться с неспособности выпустить ресурс? так выдача исключения от Располагает, просто не имеет смысла.
Однако, если я обнаруживаю внутри, Располагают то состояние программы, повреждается, лучше выдать исключение затем для глотания его, лучше для сокрушения теперь затем, чтобы продолжить работать и приводить к неправильным результатам.
12 ответов
Возможно, это было сделано для того, чтобы иметь возможность выпрыгнуть из "петли" в любой момент, например:
do
{
...
if (somethingIsWrong) break;
//more code
...
}
while(false);
Но, как говорили другие, я бы не стал делать это так.
Я собираюсь предположить, что автор этого кода не доверял своему коду, поэтому он запускал его пару раз, чтобы посмотреть, заставило ли это работать больше, и это археологические остатки это.
В качестве заполнителя для будущего, когда какое-то другое условие ставится вместо false .
Практически во всех языках, кроме C / C ++, это не дает тактического преимущества.
В C / C ++ есть случай с макросами, где do / while (false) упрощает безопасно развернуть макрос на несколько операторов. Это выгодно, если в остальном макрос выглядит как обычный вызов функции.
Взгляните на этот вопрос
OP спрашивает об этой точной конструкции и объясняет некоторые причины ее использования. Похоже, что все согласны с тем, что это плохо.
Это бесполезно, но кодировщик мог бы использовать несколько команд прерывания для какой-то странной обработки исключений.
do{
if(<something>){...}else{break}
if(<something else>){...}else{break}
...
}while(false)
Конечно, это глупо, но однажды я нашел что-то вроде старой программы на языке C.
Он используется в C для определения блока внутри макроса. См., Например, this .
Пример, следующее недопустимо:
#define f(x) { g(x); h(x); }
if (x >= 0) f(x); else f(-x);
, но с этим определением оно будет работать:
#define f(x) do { g(x); h(x) } while(false)
В Java нет причин для этого.
В C это распространенная идиома при определении макросов:
Учтите:
#define macro1 doStuff(); doOtherStuff()
#define macro2 do{ doStuff(); doOtherStuff(); } while( false )
if( something ) macro1; // only the first statement in macro1 is executed conditionally
if( something ) macro2; // does what it looks like it does
... но макросы в C - зло, и их следует избегать, если это вообще возможно.
Ваш коллега имеет опыт работы на C?
Ваша интуиция верна. Это совершенно бесполезная вещь.
Возможно , что тот, кто его кодировал, изначально имел что-то, кроме false в качестве условия, и просто изменил его на false вместо удаления всего блока, чтобы не потерять эту «историю» кода. Однако это просто хватается за соломинку. Откровенно говоря, это всего лишь простой пример тавтологии , которой нет места в коде.
Единственная причина, по которой я могу придумать, - это создать блок, чтобы сделать переменные, объявленные в пределах {...} , более ограниченными, но есть способы сделать лучше это (например, создание функций или просто создание блоков - совет Питу Киркхэму).
Его можно использовать, чтобы пропустить выполнение некоторого кода (например, goto или что-то в этом роде), но когда я смотрю на это снова, кажется, что есть цикл for (где if (...) break; операторы) в do-while . В противном случае я бы сказал, что это будет Java-версия goto ...