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

Pzz>>Мне этот код не нравится. Не нравится он мне тем, что из него может прилететь исключение. Причем в этом исключении будет сказано лишь, что оно относится к некоему constrained_value.

S>Вас куда-то постоянно уносит в сторону. И, складывается ощущение, что это от незнания инструмента о котором вы пытаетесь судить. А может и от специфического опыта.

Нет, не уносит. В программировании, за пределами школьного курса, нет такой задачи "прочитать откуда-нибудь какое-нибудь значение, и дать гарантии, что оно попадает в диапазон". Есть задачи прочитать значение из файла, ввести его от пользователя, получить по сети и т.п., и осмысленная обработка ошибок занимает больше кода, чем собственно получение значения.

Говорить об инструменте имеет смысл в контексте решения практических, а не школьных, задач. Если довести ваш пример до нормального состояния, что там был ваш constrained_value, что его не было, разница будет не шибко заметна.

S>Суть constrained_value в том, чтобы содержать заведомо корректное значение. Ответственность за получение этого значения лежит на разработчике. Соответственно, прежде чем поместить что-то в constrained_value вы можете сделать столько проверок, сколько вам нужно. И проинформировать о проблемах так, как вам хочется. Но, если вы этого по каким-то причинам не сделали, то constrained_value не позволит вам вернуть заведомо некорректное значение. И тот, кто ждет от вас constrained_value, может быть в этом уверен.

Я, вообще-то, не хочу иметь в программе переменную, которая выглядит как целочисленная, только не позволяет складывать, при каждом присваивании делает пару проверок и иногда плюется исключениями. Это совершенно вредная штука, пусть даже C++ и позволяет создавать их с легкостью.

Pzz>>В C я написал бы явную проверку.

S>И после этого вы еще чего-то говорите про человеческий фактор и его влияние?

Говорю, да. В программе на C++, скорее всего, ничего, кроме проверки, встроенной в constrained_value, и не будет. И исключение никто не будет обрабатывать до самого верха. А наверху приделают кнопочку "ой, программа упала, послать дамп разработчикам?". Таков он, человеческий фактор.

S>Рискую вас удивить, но в C++ вы запросто можете вернуть, скажем expected, которое будет содержать либо нормальный результат, либо ошибку. Что сильно лучше, чем два значения в Go, одно из которых заведомо некорректно.

Угу. А потом мы начинаем сводить в одном проекте 5 библиотек, каждая из которых содержит свою реализацию expected, совершенно идентичную 4-м остальным, но формально несовместимую с ними, потому что разные типы.