Archived
This forum has been archived. Please start a new discussion on GitHub.
Servant locators throwing application exceptions
We're developing an versioned asset management system and one of the requirements for the new Ice version from the previous CORBA version is to have an arbitrary long chained stack trace thrown to the client when anything fails. The users of our API will open tickets or email us problems and we want the entire stack trace to see what went wrong.
So we have something like
We're also storing millions of objects in the system so we also need servant locators.
The two don't mix too well. The system allows people to delete assets, so if one client has a proxy to an object and deletes it and another one later tries an operation on it, then the client will get an ObjectNotExistException; I can't throw my own application specific exceptions here. This isn't good enough; I want to know why the object cannot be found, since I have a versioned filesystem and not just a database at the back end, so the asset not being found is more complicated then a simple "the row does not exist."
So what I've implemented is a deferred or lazy initialization of the servants. The servant locator will construct a servant for any Ice identity name, so ObjectNotExistException is never thrown. Then in all servant methods, I run a initialize_servant() method that takes the Ice identity name, unserializes the constructor arguments from the name it and initializes itself. If for some reason, the object in the backend cannot be found, then I can throw any application specific exception.
It would be useful if the servant locator mechanism could be extended to allow arbitrary exceptions to be thrown. This would considerably simplify my code.
In fact, it seems that in Ice, anywhere one can extend Ice to provide implementation code, Ice should allow user exceptions to be thrown.
Regards,
Blair
So we have something like
struct SpiIceCause { string message; StringSeq stackTrace; }; sequence<SpiIceCause> SpiIceCauseSeq; exception SpiIceException { string message; StringSeq stackTrace; SpiIceCauseSeq causedBy; };
We're also storing millions of objects in the system so we also need servant locators.
The two don't mix too well. The system allows people to delete assets, so if one client has a proxy to an object and deletes it and another one later tries an operation on it, then the client will get an ObjectNotExistException; I can't throw my own application specific exceptions here. This isn't good enough; I want to know why the object cannot be found, since I have a versioned filesystem and not just a database at the back end, so the asset not being found is more complicated then a simple "the row does not exist."
So what I've implemented is a deferred or lazy initialization of the servants. The servant locator will construct a servant for any Ice identity name, so ObjectNotExistException is never thrown. Then in all servant methods, I run a initialize_servant() method that takes the Ice identity name, unserializes the constructor arguments from the name it and initializes itself. If for some reason, the object in the backend cannot be found, then I can throw any application specific exception.
It would be useful if the servant locator mechanism could be extended to allow arbitrary exceptions to be thrown. This would considerably simplify my code.
In fact, it seems that in Ice, anywhere one can extend Ice to provide implementation code, Ice should allow user exceptions to be thrown.
Regards,
Blair
0
Comments
-
We are currently discussing this internally. Off hand, I don't see a reason why we shouldn't allow user exceptions to be raised from servant locators, but we first need to investigate the implications further.0
-
I agree that it should be possible to throw user exceptions from locate() and finished(). We'll add this to the next release of Ice.
Cheers,
Michi.0