Это хорошо, чтобы конструкторы выдали исключения на этапе выполнения?

Совершенно нормально выбросить проверенное исключение, чтобы указать, что построение объекта не удалось, как уже прокомментировал Крис Джестер-Янг. Другой вопрос, является ли создание исключения unchecked - хорошей идеей. Вы потеряете ворчание компилятора, который побуждает вас перехватывать и обрабатывать исключение, что вы, безусловно, захотите сделать.

Да вполне допустимо генерировать исключение в вашем конструкторе. У вас практически нет другого выбора, кроме как сделать это, особенно когда вы просто пытаетесь сконструировать объект, и что-то просто работает неправильно .

Не уверен, полезно это или нет, но с HTTP 1.1 базовое подключение к серверу может быть не закрыто, так что, возможно, поток также не будет закрыт? Идея заключается в том, что можно повторно использовать соединение для отправки нового запроса. Я думаю, вы должны использовать контент-длину. Вместо этого можно использовать классы WebClient или WebRequest.

Если алгоритм уже ограничен/жестко закодирован с использованием только std:: vector:: iterator и std:: vector:: iterator , не имеет значения, какой метод вы в конечном итоге используете. Ваш алгоритм уже конкретизирован за пределами точки, где выбор одного из других может иметь какое-либо значение. Они оба делают одно и то же. Это просто вопрос личного предпочтения. Я бы лично использовал явное вычитание.

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

• Если используется явное вычитание, алгоритм будет ограничен довольно узким классом итераторов: итераторов произвольного доступа. (Это то, что вы получаете теперь от std:: vector )

• Если вы используете distance , ваш алгоритм будет поддерживать гораздо более широкий класс итераторов: итераторы ввода.

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

Да. Это стандартная практика.

В Effective Java, 2nd Ed. это охватывается пунктом 61 «Создать исключения, соответствующие абстракции». В пункте 58 «Использование проверенных исключений для условий восстановления и исключений во время выполнения для ошибок программирования» также рассматривается вопрос о том, проверяется ли результирующая исключительная ситуация или нет.

То, что это конструктор, а не обычный метод, на самом деле не является проблемой. (На самом деле, конструкторы, возможно, имеют больше свободы, поскольку они не связаны интерфейсом супер.)

При создании исключения в результате другого исключения рекомендуется убедиться, что вы настройками причину для нового исключения.

Лично мне неприятно видеть, как конструкторы генерируют проверенные исключения (как уже указывал doppeldish). Тем не менее, как вы можете быть уверены, что приложение не сможет обработать исключение? Даже если приложение не может с этим справиться, может, пользователь сможет, просто попробовав еще раз?

Да. Если вы не знаете, как следует обрабатывать исключение, вам лучше выбросить его, чем просто проглотить и распечатать трассировку стека (или, что еще хуже, ничего не делать).

Это поможет предотвратить в дальнейшем некоторые чрезвычайно трудные для отладки ошибки.