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

AVK>А у ТС как раз ошибки, что характерно.

Уважаемый AndrewVK, скажите как бы вы отреагировали на такую ситуацию: вот приходите Вы на собеседование, Вам дают листик с исходным кодом и спрашивают "имеются ли в этом коде ошибки?". Обнаружив такую в коде Вы начинаете с криками "Ааааа... КАРАУЛ! ОШИБКА!" метаться и бегать по комнате для собеседований, вместо того чтобы спокойно сказать, что да, ошибка есть и заключается она в том-то и том-то.
Исключительные ситуации это не средство информирования клиентов функций/библиотек о состоянии объектов, а средство оповещения что что-то в программе идет не так как запланировано и игнорировать это нельзя. В данном же случае предполагается обычная проверка на доступность удаленного клиента. Неужели то, что клиент прервал сессию это является ошибкой? Или даже если невозможность доставить сообщение происходит именно из-за ошибки в сети, то надо просто вернуть уведомление, что объект недоступен по такой-то причине.
Вообще, полезность данной функции для меня крайне сомнительна. Если она применяется для того, чтобы перед отправкой сообщения проверять можно ли это сделать (а судя по всему это так), то так делать нельзя, так как это чревато крайне редкими сбоями которые объяснить будет впоследствии невозможно. Все дело в том, что после проверки можно ли доставить сообщение удаленному клиенту и получение "утвердительного ответа" мы пытаемся это сделать, рассчитывая на то, что с клиентом все в порядке. Но за это время (после проверки и до начала доставки сообщения) с клиентом может что-то случиться вследствие чего доставить сообщение не удастся. Т.е. архитектурно верным решением было бы перенести эту проверку в саму функцию отправки. А вот в ней, уже в случае ошибки необходимо кидать именно исключения, потому что функция не может выполнить свое предназначение и игнорировать это нельзя и это именно как раз тот случай, где надо использовать исключения.