Даже если вы знаете, что поиск у вас с одним исходом (элемент будет в последовательности), лучше не вырождать цикл WHILE до полного прохода.

Пример - знаем, что в разбираемом тексте впереди нас ждёт вьюшка:
> -- Цитата:
> r.ReadChar(ch);WHILE ~(rd.view # NIL) DO  .. что-то делается с ch..  rd.ReadChar(ch)END

Теперь представим, что указанный фрагмент программы получает неверный фрагмент текста, где вьюшки нет. Получаем зависание. И можем долго ломать голову, что не так. Ещё неприятнее, если это дойдёт до конечного продукта.

Вместо этоговсегда используем линейный поиск с двумя исходами, только если мы знаем, что исход должен быть один (найдено), то вместо IF в конце ставим ASSERT с кодом инвариантного утверждения (от 100):

> -- Цитата:
> r.ReadChar(ch);WHILE ~rd.eot & ~(rd.view # NIL) DO  .. что-то делается с ch..  rd.ReadChar(ch)END;ASSERT(~rd.eot, 100);

Таким образом, зависание превращается в сбой на вполне понятном утверждении.
Останов намного лучше зависания.

Пример - из реальной ситуации. Человек разрабатывает компонент системы, и сейчас мы разбирали вот это место. И пришли к изложенному здесь правилу.
А компонент-то серверного назначения... И останов нормально обработается, а вот зависание - уже хуже; необходим перезапуск экземпляра ББ.

Ещё один важный вывод:
Пока мы остаёмся в рамках двух базовых схем - полный проход и линейный поиск, зависаний при некоторых входных данных можно не опасаться..
Подкреплено длительным опытом. Ошибок на зависание в своей практике не припоминаю. Т.е. если изменение в цикле сделано неверно - то он зависает в принципе, независимо от входных данных.