Re: Error reporting in Cocoa (was Re: Exception not being caught)
Re: Error reporting in Cocoa (was Re: Exception not being caught)
- Subject: Re: Error reporting in Cocoa (was Re: Exception not being caught)
- From: Kyle Sluder <email@hidden>
- Date: Tue, 22 Mar 2011 08:17:46 -0700
On Tue, Mar 22, 2011 at 8:07 AM, A.M. <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden