всем привет.
представьте следующую ситуацию..
у вас есть некоторый удаленный объект, методы которого вы вызываете:

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

какие варианты реализации есть?

всем спасибо.


Это сообщение отредактировал(а) boostcoder - 23.11.2010, 08:59

boostcoder

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



что-то вроде этого

azesmcar, т.е. получается так, что вызов метода реализации должен происходить в try {} блоке. в catch блоке я определяю тип исключения(если нужно). этот тип должен содержать всю необходимую информацию(строка/файл/сообщение/тип). далее я сериализую эту информацию и отправляю вызывающей стороне.
вызывающая сторона в свою очередь получает от сервера ответ. и если тип ответа = исключение - тогда сгенерировать его локально.

...

Да, но все это скрыто от пользователя. Пользователь просто вызывает удаленный метод и получает исключение.

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

Добавлено через 31 секунду

да да.
 я просто размышлял вслух  

да, но клиент когда нибудь должен запросить ответ от функции? Вот тогда и получит: либо ответ, либо исключение.

нет  
все зависит от реализации логики.

а откуда тогда получать исключение?  

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

Добавлено через 55 секунд

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

У вызывающей стороны ДОЛЖНО быть четко оговоренное место (или места), где она может принять исключение. Исключение не должно сваливаться в поток исполнение в произвольном месте. Во первых - такое исключение невозможно логически привязать к вызову (т.к. вызов был произведен давным давно и вообще неизвестно какой именно), во вторых - такое исключение может сломать (и скорее всего и сломает) поток исполнения, т.к. он (поток) может не рассчитывать на то, что в этом месте вообще возможно исключение

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

Кстати, DCOM требует, что бы все методы возвращали HRESULT - он туда складывает и свои собственные ошибки (сетевые)

А я думал асинхронные операции бывают в виде:
а) callback при завершении, куда передается сложный объект, из которого можно узнать об успехе операции+получить описание ошибки. При этом не оговорено насчет в каком thread-е этот калбэк вызывается
б) опрашивание об окончании операции. По сути своей частный случай обертки над (а). Тут callback вызывается внутри "ядра" и сложный объект сохраняется куда-то там, чтобы при опросе его вернуть.

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

понимаю.


ага.


я к такому же выводу пришел.


Вы правы. из-за "туманности" в принципах и реализации, решил отказаться от подобной возможности.

всем спасибо. вопрос закрыт.