При создании современных программ программисту приходится учитывать множество факторов. Это порождает довольно сложную логику работы программ, чтобы в критический момент программа не вылетела и её интерфейс был интуитивно понятен пользователю.
Интуитивно понятный интерфейс – это не только стандартные значки (иконки) на кнопках, панелях инструментов или в меню программы. Некоторые команды программы можно выполнять только при определённых условиях. Например, перемещение элемента вверх в списке (ListBox) возможно, если в списке, во-первых, выбран какой-либо элемент, а во-вторых, этот элемент не является первым. Программисты знают, что в большинстве языков программирования, если в ListBox’е не выбран ни один элемент, то индекс выбранного элемента равен -1, а индекс первого элемента – 0. Не знаю, существуют ли какие-то экзотические языки программирования, где этот принцип нарушается.
При этом программа должна ненавязчиво показать пользователю, когда данная операция возможна, а когда нет. Это делается путём блокировки или разблокировки соответствующих кнопок на панели инструментов. Всё это требует от программиста внесения дополнительной логики в программу на любом языке программирования.
С другой стороны, если мы присвоим значение элементу массива с индексом -1 (в большинстве языков это недопустимая операция), то по логике перед выполнением данной операции мы должны проверить её параметры на допустимые значения и только после этого выполнять операцию. Если мы этого не сделаем, то в языках с контролируемыми исключениями (C#, Java, Python) произойдёт исключение. В C++ спецификации исключений (throw(typeid)) были признаны устаревшими в стандарте C++11 и полностью удалены в C++17, так как вызывали много нареканий у разработчиков. Однако сама обработка исключений (try/catch) осталась и широко применяется.
Но если мы перед выполнением операции будем проверять аргументы команды на допустимые значения, то команда будет выполняться всегда, не сигнализируя программисту или отладчику, что была попытка выполнить недопустимую операцию. А такая попытка говорит о том, что в программе нарушена логика работы интерфейса пользователя.
Перед программистом при создании программ стоит множество задач, поэтому он может переключиться на другие и забыть реализовать интерфейсную логику, связанную с данной командой. Но если отсутствует проверка условия выполнения, программа сама напомнит ему, что логика доступности команды либо вообще не реализована, либо реализована неверно. Ему придётся к ней вернуться. А это повысит качество кода, и интерфейс станет более понятным для конечного пользователя.
Конечно, есть ошибки, которые нельзя предотвратить таким способом: например, если пользователь подсунул файл не того формата или в результате длительного расчёта произошло деление на ноль. Обработка таких ошибок должна обязательно присутствовать и выдавать пользователю соответствующее сообщение.
Таким образом, отсутствие в коде некоторых проверок на допустимые значения способствует созданию более качественного программного продукта.