Когда повторно вызывать исключение, а когда возвращать FALSE?

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

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

В последнее время я больше склоняюсь к «не бросать исключение, если оно того не стоит». Наши исключения выполняют много работы: они регистрируют данные, создают трассировки стека и т. д. Если я просто хочу преобразовать строку в целое число, генерировать исключение, если входная строка имеет неправильный формат, вероятно, не стоит. С другой стороны, у меня есть объекты, которые мне просто не нужны в моей системе, если они не могут быть построены из правильных данных, и в этом случае их конструкторы выдают исключения.

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

Я бы пропустил исключения. В противном случае вы маскируете потенциально важную информацию, которая может быть полезна позже. Я знаю, что вы не используете его сейчас, но что, если вы решите в будущем обрабатывать восстановление по-другому в зависимости от типа ошибки. На этом этапе вам нужно будет отменить весь код, который вы написали, чтобы замаскировать исключение. Хотя я не согласен с @MadKeithV в отношении того, чтобы сделать его истинным / ложным, я думаю, что он имеет смысл обернуть исключение в ваше собственное исключение, которое, возможно, имеет лучшую семантику для вашего приложения.

Я считаю, что принцип механизма исключения - это теория "быстро потерпеть неудачу".

Вы хотите, чтобы клиентское приложение «быстро выходило из строя» при неудачном соединении?
Если да, просто отбросьте исключение или инкапсулируйте исключение в собственное прикладное исключение.

Если клиент проигнорирует это исключение, его приложение остановится.

Возврат false означает, что клиент может проигнорировать проблему, его приложение все равно может вылететь, но «позже» ...

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

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

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

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

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

Я бы предложил второй. Ответственность за обработку исключения и принятие правильных действий в соответствии с исключением будет лежать на вызывающей стороне. Предположим, Connect выдает исключение AccountExpiredException, NetworkUnavailableException, InvalidCredentialsException и т. д. (Это всего лишь примеры). Я могу предложить пользователю «исправить» исключение (обратитесь к администратору, проверьте сетевой кабель, проверьте имя пользователя / пароль). Я бы даже предложил удалить возвращаемое значение (индикатор) и просто сделать его недействительным. Взгляните на метод SqlConnection Open - он похож на метод Connect - он не возвращает значение, а выдает исключение. Чтобы проглотить такое исключение

 bool MyHardwareObject.Connect()
{
    try
    {
        ThirdPartyLibrary.Connect();
    }
    catch (SomeException)
    {
        return false;
    }
    return true;
}

ИМХО не очень хорошая идея. Я бы порекомендовал вам реализовать шаблон IDisposable. Только мои 2 цента.

Прочтите это: http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html

Суммируя:

Может ли вызывающая сторона использовать возвращаемое значение? Сможет ли он вылечить или ошибка конец света? Если это небольшая проблема, используйте код возврата. Если различные состояния происходят одинаково часто (в 50% случаев происходит сбой, в 50% это работает), используйте код возврата, потому что вызывающий должен обрабатывать ситуацию в любом случае, и исключение не помогает.

Вы хотите пропустить дополнительную информацию (например, настройку стороннего устройства, чтобы у кого-то была возможность отладить то, что произошло позже)? Используйте исключение.