Теперь буду везде ставить. Собственно, это ничем (кроме ручной писанины) не отличается от CASE и WITH без ELSE.

Free 0 .. 19 use for temporary breakpoints
Preconditions 20 .. 59 validate parameters at procedure entry
Postconditions 60 .. 99 validate results at procedure end
Invariants 100 .. 120 validate intermediate states (detect local error)
Reserved 121 .. 125 reserved for future use
Not Yet Implemented 126 procedure is not yet implemented
Reserved 127 reserved for future use

Может лучше HALT(126)?

Это охрана от логической ошибки. Когда программист думает, что предусмотрел все случаи, а на деле выходит не так.

One downside of object-orientation in systems as complex as BUGS is that it can make debugging
somewhat difficult. In more traditional programming settings, there would typically be some kind
of master program specifying a list of commands to be executed in sequence. A debugger can
then be implemented to step through each command in turn and provide current information on
parameters of interest. In contrast, objects are generally designed only to make/respond to various
requests of/from other objects—they have little or no concept of the order in which external events
occur. Consequently, an object-oriented program typically behaves as a complex chain-reaction
and the path back to the source of any error may be extremely convoluted. This can make for
indecipherable error messages, error messages that have nothing to do with the actual error, and
impenetrable ‘trap’ windows, all of which even the developers of the software sometimes struggle
to understand. For example, an ‘undefined real result’ trap lists the sequence of ‘function calls’ that
led to some impossible calculation, such as the square root of a negative number. The calculation
in question may have been attempted by an updater object trying to evaluate some function of
interest. To figure out what the updater was trying to do, which node it was dealing with at the time,
what the current values of that node and those in its Markov blanket are, and why these might have
led to some inconsistency (even if it were that simple), just from a list of function calls and the
current values of some ‘internal’ parameters, is a challenge indeed. As developers of the software
we have access to special tools for probing these ‘traps’ for more information but it can still be
difficult sometimes. It has been particularly difficult to fix any of these traps, or replace them with
more meaningful error messages, since they represent unanticipated errors—things that were not
meant to go wrong—it is virtually impossible to get hold of enough contextual information to
provide a message that might be of some use to the user.

Возникает подспудное подозрение, что проблеме охраны от нарушения инвариантов авторы таки уделили недостаточно внимания:-(

Нарушение инварианта из-за ошибки в программе.
Тоже самое, если тут трэпанёт invalid case при x=4

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

Ветвь else обязательна. По умолчанию она генерирует сигнал отказа... Программист при желании может заменить генерацию сигнала отказа на иное действие.

Есть один момент: пока я на практике сталкивался с необходимостью ставить стопор в многоветочном IF (есть ELSIF).

Если же речь идёт о простом одноветочном типа IF x < 0 THEN x := -x END, обязательный ELSE может быть излишен...

Кстати, еще один обязательный паттерн.

Ну да. К "циклу Дейкстры" добавился "выбор Дейкстры".

Это имеется в виду "if-fi" (как в Promela)?..