Здравствуйте.

Допустим, по проекту метод получает на вход натуральное число. Надо ли внутри метода проверять это? С одной стороны, так надежнее, с другой — лишние проверки, скрывающие ошибки в других модулях. Как будет правильнее?

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

MP>Допустим, по проекту метод получает на вход натуральное число. Надо ли внутри метода проверять это? С одной стороны, так надежнее, с другой — лишние проверки, скрывающие ошибки в других модулях. Как будет правильнее?
Называется принципом недоверия, только не понятно, почему это скрывает ошибки ? Если вы вышли за границу массива и получили эксепшин, это не означает, что проблемы в ядре вашего языка ...

C_K>Называется принципом недоверия, только не понятно, почему это скрывает ошибки ? Если вы вышли за границу массива и получили эксепшин, это не означает, что проблемы в ядре вашего языка ...
Насчет сокрытия пока не могу придумать пример... Так проверять или нет? От чего зависит?

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

MP>Здравствуйте.

MP>Допустим, по проекту метод получает на вход натуральное число. Надо ли внутри метода проверять это? С одной стороны, так надежнее, с другой — лишние проверки, скрывающие ошибки в других модулях. Как будет правильнее?

Это надо было решать при проектировании. В принципе, в документации к этому методу можно явно указать то, или иное. А вообще, смысл этой проверки? Если на вход дано плохое число, то у вызывающего явно что-то не так и ничего с этим уже не поделаешь... На мой взгляд, лучше пусть сам думает, что он передает, а проверки в методе делать только в отладочной версии (из релиза можно/надо исключить).

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

MP>Насчет сокрытия пока не могу придумать пример... Так проверять или нет? От чего зависит?
Нет универсального решения. Проверки возможно позволят на ранних стадиях диагностировать ошибку (проблему в данных/программе/и т.д.), излишние проверки продавят perfomance.

Mikhail Polykovsky пишет:

> Здравствуйте.
>
> Допустим, по проекту метод получает на вход натуральное число. Надо ли
> внутри метода проверять это? С одной стороны, так надежнее, с другой —
> лишние проверки, скрывающие ошибки в других модулях. Как будет правильнее?
>
Просто нужно определится с самого начала с обработкой некорректных
переметров функции
(да и вообще всех ошибочных ситуаций), либо это будет exception (либо
возврат кода ошибки,
зависит от выбранной платформы) либо это aseert.
Выбор моет зависеть от следующих факторов (в частности для функций):
— ответственность за передачу корректного параметра
а) лежит на вызывающей стороне, тогда assert в самом начале функции
б) лежит на вызываемой стороне, тогда exception
— уровень, на котором вызывается функция
а) граничная функция приложения (например функция вашей dll, которая
подгружается
сторонним приложением), тогда использование некорректных параметров должно
оповещаться кодом ошибки (exception).
б) внутрення функкция (библиотека функциями утилитами, которая
используется внутренними
компонентми, то здесь можно смело ставить assert, чтобы на этапе
разработки приложения выявить
неправильное использование этого модуля)

imho разумеется.

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

MP>Допустим, по проекту метод получает на вход натуральное число. Надо ли внутри метода проверять это? С одной стороны, так надежнее, с другой — лишние проверки, скрывающие ошибки в других модулях. Как будет правильнее?

Есть такое понятие, как область доверия. Так вот, стоит доверять только тем значениям, которые приходят из источника, которому ты доверяешь, в противном случае необходимо делать проверку входящей информации. Обычно низкий уровень доверия ставится при взаимодействии 2-х разных систем. Если у тебя взаимодействуют 2 твоих класса или модуля и ты уверен в том, что параметры всегда в нормальном состоянии, то дополнительных проверок делать не стоит.

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

S>Есть такое понятие, как область доверия. Так вот, стоит доверять только тем значениям, которые приходят из источника, которому ты доверяешь, в противном случае необходимо делать проверку входящей информации. Обычно низкий уровень доверия ставится при взаимодействии 2-х разных систем. Если у тебя взаимодействуют 2 твоих класса или модуля и ты уверен в том, что параметры всегда в нормальном состоянии, то дополнительных проверок делать не стоит.

Точно. Я всегда так и делаю.
Бывают правда редкие исключения, когда подсистема выставляет наружу очень маленькие методы, которые должны быть еще и очень быстрыми. Тогда лишние проверки неуместны и все остается на совести вызывающей стороны.

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

MP>Здравствуйте.

MP>Допустим, по проекту метод получает на вход натуральное число. Надо ли внутри метода проверять это? С одной стороны, так надежнее, с другой — лишние проверки, скрывающие ошибки в других модулях. Как будет правильнее?
Ко всем предыдущим постингам могу добавить только одно: Если система реального времени, то ассерты делать низя . Приходится писать обработку, которая пытается понять что именно хотела вызывающая функция. Если сие не возможно, то возвращаем ошибку или печатаем БАГ.

Сухой остаток: нужно сначало решить что нужно, а потом следовать концепции... Все зависит от проекта. Можно только дать рекомендации, когда что использовать.

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

S>Есть такое понятие, как область доверия. Так вот, стоит доверять только тем значениям, которые приходят из источника, которому ты доверяешь, в противном случае необходимо делать проверку входящей информации.
К сожалению в нашей жизни ни кому доверять нельзя. Так что лишний ассерт в дебаг версии никогда не помешает. А в релизе, возможно, можно какой то части кода довериться.

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

S>>Есть такое понятие, как область доверия. Так вот, стоит доверять только тем значениям, которые приходят из источника, которому ты доверяешь, в противном случае необходимо делать проверку входящей информации.
CVL>К сожалению в нашей жизни ни кому доверять нельзя.
Спорно, конечно.

CVL>Так что лишний ассерт в дебаг версии никогда не помешает.
Полностью согласен. Реализуемо как в коде, так и в unit-тестах.

CVL>А в релизе, возможно, можно какой то части кода довериться.
А доверие определяется для релиза. Для дебага trust no one, пока не релиз.

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

MP>Здравствуйте.

MP>Допустим, по проекту метод получает на вход натуральное число. Надо ли внутри метода проверять это? С одной стороны, так надежнее, с другой — лишние проверки, скрывающие ошибки в других модулях. Как будет правильнее?

Можно описраться на понятие бизнес-правил.
Вы ввели бизнес-правило, утверждающее, что "число должно быть натуральным".
Если участвуют в бизнес-процессе два "контрагента", то вам нужно определить, кто из них реализует данное бизнес-правило. Тогда будет понятно, кто должен проверять. Если оба должны это бизнес-правило реализовывать, то проверка в двух местах.

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

MP>Здравствуйте.

MP>Допустим, по проекту метод получает на вход натуральное число. Надо ли внутри метода проверять это? С одной стороны, так надежнее, с другой — лишние проверки, скрывающие ошибки в других модулях. Как будет правильнее?


Попробуйте поискать информацию о программировании по контракту

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

MP>>Допустим, по проекту метод получает на вход натуральное число. Надо ли внутри метода проверять это? С одной стороны, так надежнее, с другой — лишние проверки, скрывающие ошибки в других модулях. Как будет правильнее?

S>Есть такое понятие, как область доверия. Так вот, стоит доверять только тем значениям, которые приходят из источника, которому ты доверяешь, в противном случае необходимо делать проверку входящей информации. Обычно низкий уровень доверия ставится при взаимодействии 2-х разных систем. Если у тебя взаимодействуют 2 твоих класса или модуля и ты уверен в том, что параметры всегда в нормальном состоянии, то дополнительных проверок делать не стоит.

а еще есть такое понятие, как доверяй но проверяй! поэтому ASSERT у меня почти везде, а вот проверки только на 20% функций.

OFF: сейчас как раз по этому поводу много приятных слов не по адресу. последний билд World Of Warcraft маркирован такой маааленькой лэйбой в правом нижнем углу (Build Assert Enabled) и на самопальных серваках народ каждые пять минут вылетает