Здравствуйте, Sinclair, Вы писали:

A>>Абсолютно такое же ощущение/практика. Единственно, что это не только с исключениями так работает, но и с кодами возврата, и с просто некорректными результатами ака "обычно не бывает" — которые просто игнорируются, пока это возможно, если "не давать по рукам". У исключений есть даже преимущество в этом случае — они хотя бы не игнорируются по умолчанию, а вылетают выше уровнем и их легче задетектать, чем проигноренный результат от которого никаких следов может и не остаться к моменту неадекватного поведения.
S>То, о чём вы говорите — тяжкое наследие "ассемблерноподобных" языков с рудиментарными системами типов.

Не согласен. Артефакт слабой системы типов тут имеет вклад безусловно, но не думаю, что он является решающим. Желание писать только happy-path, а остальное проигнорировать (ака оптимистичное программирование) — это скорее всего атрибут психики человека, а требовать от него проверить все возможные условия — только способ заставить искать обходные пути, чтобы это не проверять, а проигнорировать при любой возможности. Собственно мы это и наблюдаем в эволюции различных языков программирования — ака static vs dynamic, например.

S>А современные языки оборудованы, в том числе, и exhaustiveness-checking. То есть если у меня тип значения — это "number | string", то мне недостаточно просто обложить арифметическую операцию с ним проверкой вида if(x is number) return x + 1;. Компилятор может и должен бить меня по рукам, "э-э-э, а ты не написал, что делать если там string!".
S>Строгая типизация сильно помогает в таких случаях. Но сильно упарываться в эту сторону становится контрпродуктивным, т.к. сложные системы типов становятся некомфортными в использовании как для разработчика, так и для компилятора.

Это хорошо выглядит в теории и при методе "аккуратного" программирования. А на практике всё также прекрасно игнорируется и код начинает весь выглядеть как "мамой клянусь тут всегда number", а если вдруг не number — то тогда произвольное валидное значение — например 0.

И даже современные языки в большинстве своём прекрасно живут с игнорированием, например, проблемы переполнения int32 в системе типов. Хотя это тоже артефакт "ассемблероподобных" языков и устройства процессоров собственно. Никто не хочет писать код пессимистично в этом случае и обрабатывать все возможные кейсы (ака exhaustiveness-checking).

--
С Уважением, Andir!