Исключения и коды результатов для класса клиента сокета

Question

У меня есть класс, который инкапсулирует связь через сокет tcp с сервером. Для каждого командного сообщения, отправляемого на сервер, сервер будет отправлять обратно ответное сообщение, которое неизменно содержит код ответа (OK, Fail). Используя мой класс, каждая команда может быть выполнена либо синхронно, либо асинхронно.

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

Итак, сейчас мои методы команд синхронизации возвращают перечисление, которое может иметь следующие значения: OK, Fail, Fault. Если возникает исключение, оно просто вызывается в вызывающем потоке (в команде синхронизации). Для асинхронных команд значение enum свойства Result может содержать дополнительное значение: OK, Fail, Fault или Exception, и обратный вызов может получить доступ к реальному объекту исключения через свойство Exception объекта команды.

Что вы думаете об этой стратегии? Я испытываю искушение вообще не вызывать исключения для команд синхронизации, а просто регистрировать исключение внутри и возвращать вместо этого значение 4-го перечисления, потому что это все, что я действительно сделаю с исключениями в любом конкретном случае в любом случае ... Или я не должен использовать вообще коды результатов и просто выдают исключения во всех случаях, даже при сбоях?

Спасибо.

Answer 1

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

При вызове yourObject.BeginAsyncUploadFile () я ожидал бы того же поведения, за исключением того, что мне нужно было бы подождать для IAsyncResult или эквивалентного объекта, чтобы выяснить, успешно ли была загружена файл, и затем проверить исключение / ошибку собственности, если это не так.

Answer 2

Я думаю, что ваша стратегия в основном здорова.

Имейте в виду, что целью исключений является работа с исключительными условиями. Чем ближе к источнику проблемы, тем лучше.

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

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

Моя философия в отношении исключений заключается в том, что они должны соответствовать исключительным условиям, с которыми вы не можете иметь дело. Закрытая розетка? Хм ... сколько раз интернет отключается у меня дома ...

Answer 3

Это довольно интересный вопрос. Таким образом, вероятно, нет «100% правильного» ответа, и в основном это зависит от того, как, по вашему мнению, должен быть структурирован код, использующий вашу функцию.

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

Теперь, если у вас нормальная и ожидаемая ситуация, вам, вероятно, следует вернуть значение ошибки. Таким образом, код знает, что ему нужно «стараться изо всех сил», но это не скомпрометирует то, что произошло.

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

Но тогда красота в глазах смотрящего, и некоторые люди скажут вам использовать только исключения, другие (в основном программисты на C) используют только коды возврата. Просто помните, исключения должны всегда быть исключительными. :)

Answer 4

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

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