merk писал(а):
в ваших же обьяснениях, имеется ввиду доклад - считается что актер приемник существует, актер источник знает его uid, и актер источник уверен, что любая мессага посланная им актеру приемнику гарантированно доходит. а это неверно принципиально.
Проблема ясна - и весьма интересна.
Формально, в общем, я бы описал её так:
поверх абстракций низкого уровня с меньшими гарантиями мы хотим построить слой других абстракций с большим уровнем гарантий (усиливаем инварианты).
Возникает очевидная проблема: как компенсировать эти различия в гарантиях? Кто будет "дообеспечивать" их?
Ну, в сетях эта проблема решена стеком протоколов. Там как раз идёт усиление гарантий - и в итоге разработчик имеет абстракцию надёжного канала, и уже не должен контролировать корректность передачи данных. Ошибки обрабатываются ниже.
По такому же принципу можно "наслоить" между сетевым соединением и descriptor.Call слой, который "дообеспечивает". И в случае отказа соединения, исчезновения объекта и т.п. этот слой не должен выплёскивать проблему клиентскому коду, а должен приводить в действие какие-то спец. обработчики исключения, которые уже принимают конкретные решения - восстанавливать соединение, пересоздавать объект, предложить объект-заменитель, сообщить об ошибке кому-либо и т.п.
Обработкой этого занимается само приложение, но не в тех местах, где описана логика нормального взаимодействия (идут прозрачные вызовы), а в обособленных обработчиках. Т.е. основной код "прозрачен", а разница в гарантиях компенсируется специальными сценариями, которые приходят в действие в особых ситуациях.
Тут же к вопросу об обработке исключений - мне кажется, что конструкции try-except (в полезности которых многие давно сомневались) совершенно бесполезны в параллельных приложениях. Т.к. искать обработчик исключительной ситуации раскруткой стека текущего потока бессмысленно, этот поток не может и не должен ничего знать об обработке исключений (а если всё-таки должен, то достаточно обычных кодов ошибок).
Обработчики исключений должны быть обычными callback-объектами, с соотв. конкретным возможным проблемам интерфейсами. Приложение описывает эти обработчики и регистрирует их в соотв. службе. Т.е. никаких спец. языковых механизмов, только обычные ОО-паттерны.