On Tue, Mar 22, 2011 at 8:07 AM, A.M. <age...@themactionfaction.com> wrote: > I am curious as to how you would propose to add error: handlers to DO calls > considering that DO is meant to transparent and cannot modify method > signatures. For example, assuming you were designing a new DO framework, how > would you propose changing this: > > int junk = [secretlyDistantObject calculate:4]; > > to allow for a socket timeout? Would you then wrap any API which could be > potentially called by DO with the additional error: argument?
Good practice probably won't allow "secretly distant" objects to leak into the rest of the app. But that doesn't solve your problem: how does DO report DO errors without modifying message signatures? Exceptions really are the only answer. As long as DO is internally safe with respect to DO exceptions, this is okay. It's when you start introducing foreign exceptions that implementation gets hairy. Rick was attempting to handle exceptions in his client code that were being thrown through HessianKit. Because of Cocoa's attitude towards exceptions, this isn't guaranteed to work. The lack of exception support across a forwarding boundary is a significant change in language behavior that fails to fulfill the language's contract, but fixing it won't actually solve Rick's problem, which is that he's trying to throw exceptions through stack frames he doesn't own. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
