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