Там всё началось с того, что COPY обрезает данные молча, когда они не помещаются в приёмник. Данное поведение взято за дурной пример в некоторых других местах. От этого я словил по лбу граблями, когда вставил юникод туда, где он в-общем-то может быть, но обрабатывается некорректно. Поскольку ассерта не было и контроля на отсутствие не-латиницы тоже не было, файл описания конфигураций просто обрезался в произвольном месте.
Так вот, до обсуждения ассертов стоило бы спросить, почему для числовых типов потеря данных требует каких-то явных телодвижений, а для строковых оно является умолчанием и происходит легко и непринуждённо? Раньше, когда я пытался построить рекламу "Оберона против С++", тот же Сергей мне справедливо указал, что Оберон создавался не как надёжный язык, а как учебный. В чём-то он случайно оказался надёжнее Си, но это не было целью. Поэтому, если в языке вы получили граблями по лбу, то надо было читать документацию, а не рекламу.
Моя точка зрения остаётся такой, что обрезать данные молча, неявно и по умолчанию - это гораздо хуже любых ассертов. Но я и не оберонщик. Я - за другой, лучший оберон, в котором догмой будет не следование обстоятельствам Вирта и решениям, которые из них вытекали, а дружественность к кибербезопасности и к надёжности оборудования. Оберон близко к этому, но он не в этой точке. Ряд решений, в т.ч. и вот это с COPY, да и некоторые другие, опасны. Я воспринимал Оберон как отправную точку. Просто я уже это забыл, пока возился с A2. А потом вообще увяз в переводе и не факт, что куда-нибудь сдвинусь дальше. Благодарю Сергея за напоминание.
Дальше, там шла речь, что если мы оставим ассерт, то девушка в солярии сварится, и поэтому ассертов в промышленном коде быть не должно, а вместо них должна быть обработка ошибок. Неплохо бы, если бы Сергей ответил на вопрос - а если в соседний дом ударила молния, часть оборудования солярия сгорела, но модуль управления уцелел (возможно, не весь или с изменённым содержимым памяти) - как без исключения (и без рантайм-проверок) об этом можно узнать? Контроллер будет продолжать работать и девушка всё равно сварится.
В случае солярия есть безопасное состояние - выключить солнце. Понятно, что если речь идёт о летящем самолёте, то там этого нет. Но если такое состояние есть, а Сергей ведь сам выбрал свой пример, то наличие ассерта лучше его отсутствия, если обработка исключения состоит в отключении солнца. Притом, обработка исключения может происходить каким-то внешним аппаратом, более простым, чем компьютер, который просто принимает исключение по некоему проводку, отбирает управление у компьютера и тупо всё гасит. В атомной энергетике безопасные умолчания доходят до ловушек кориума - не знаю, внедрили их или нет, но насколько я в курсе, там рассматриваются всеразличные сценарии аварий и отказы любого оборудования. Во всяком случае, на бумаге это делается. Или например на железной дороге: высокое давление воздуха в тормозной магистрали - это отпущенный тормоз, а атмосферное - зажатый. Если порвался шланг, поезд автоматически тормозит. Сделай наоборот - никакие компьютеры не помогут предотвратить жертвы. Ассерт - это динамическая проверка на тот случай, когда мы не в силах были что-то предусмотреть, а также это проверка того, что в системе "всё идёт как надо". Да, им можно злоупотребить. Но ведь если его убрать, а оставить COPY с обрезанием буфера, то девушка тоже сварится, просто мы даже не будем знать, отчего это произошло. Т.е. убрать все ассерты - это значит верить в то, что в программе больше нет ошибок, а это слишком самонадеянно.
Я считаю, что компьютеры уже настолько значимы в нашей жизни, что ассерты должны оставаться и в промышленной эксплуатации. Да и вообще, расстояние между промышленным и отладочным кодом должно быть минимальным, потому что эти коды могут кардинально отличаться на компиляторах типа gcc. То, что у оберона мало флажков (было изначально) - это прекрасно и нужно стараться это сохранить. Что происходит при падении ассерта - это уже отдельный вопрос.
|
. Вы даже приписываете Вирту решения, которые имеют к нему такое же отношение, как ЯОС.