Если я что-то не упустил, я думаю, вы захотите перехватить исключение и работать соответственно (например, возвращать обратный вызов с недействительным сообщением сеанса?).
Кроме того, вы могли бы реализовать тайм-аут при асинхронном ожидании обратного вызова, поэтому даже когда сеанс истек, или сеть отсутствует, или Apocalypse разрушает сетевые коммуникации, ваш клиент может вернуть контроль и сообщить пользователю.
«Пожалуйста, войдите снова и попробуйте, проверьте вашу сеть и проверьте на наличие признаков конца дней.»
РЕДАКТИРОВАТЬ : В соответствии с запросом обратной связи, здесь немного подробнее рассказывается о моих мыслях о взаимодействии сервер-клиент, которое вы должны иметь.
Основная проблема, с которой вы сталкиваетесь, заключается в том, что происходит какое-то событие (истечение срока сеанса или неожиданный сбой), которое не позволяет клиенту узнать, что сервер никогда не ответит. Вы не можете планировать катастрофические сбои, но вы наверняка можете планировать недопустимые сеансы, недействительные аутентификации, недопустимые данные и так далее. В таких случаях сервер, вероятно, должен быть более многословным, особенно если вы работаете с моделью тонкого клиента, которая будет ничего не делать, пока сервер не отправит ответный сигнал.
Но тогда как справиться с настоящими сбоями, когда общение не происходит? Если вы можете считать, что могут возникнуть ошибки связи (и я действительно рекомендую вам это сделать), вы должны сделать своего клиента достаточно умным, чтобы хотя бы справиться с ошибками связи. Важно, чтобы это было сделано, потому что, во-первых, связь не настолько надежна (происходят неправильные конфигурации, сбои оборудования и т. Д.). Во-вторых, когда такое происходит, вы рискуете исчезнуть из-за своей функциональности или действительно плохо работаете с пользователем. Не то, чтобы ошибки удобны для пользователя, но более отзывчивые приложения.
TL; DR: Обеспечение обратной связи на стороне клиента и пользователя, если необходимо. Важно, чтобы оба знали , что происходит.