On Mar 21, 2011, at 2:19 PM, Rick Mann wrote: >> You can't currently throw an exception across a forwarded call. When the >> exception unwinder hits the forwarding frame, it stops and the exception >> goes uncaught. You'll need to put your exception handler at a different >> level. > > Hrm. This is actually a bit of a pickle. HessianKit implements the Hessian > RPC API. It does so by having the client declare a protocol (and a mapping > from Obj-C-to-Java method signatures), and the providing an implementation > for the selector. In this case, my code is actually calling a selector that > results in an invocation of a method on my server. > > There really is no place for me to put an exception handler. I could modify > HessianKit, and trap exceptions in the forwarding code, but there's no way to > report the error back to my calling code.
That’s a bit of an issue anyway, for which it would probably be worth modifying HessianKit: Regardless of one’s feelings on the topic, exceptions are not an appropriate mechanism for handling either control flow or error reporting in Cocoa or Cocoa Touch code. The reason is that if your exception crosses any stack frame you don’t fully control, all bets are off when it comes to the state of your program. The frameworks have all been written with the assumption that exceptions are only for catastrophic (non-recoverable) failures, and that the only way to respond to an exception is to terminate the application as gracefully as possible. When writing code to interoperate with Cocoa and Cocoa Touch, everyone needs to follow the same pattern; this is an area where (as you’ve found) impedance mismatch will cause problems. Ultimately, the solution will be to modify HessianKit -- or any other framework that presents an RPC-style interface[1] -- to follow the Cocoa convention of returning BOOL (or a non-nil/nil object reference) to indicate success or failure, and to fill in an NSError passed by reference if the caller desires additional failure details. -- Chris [1] Distributed Objects doesn’t work this way - it predates NSError and uses exceptions, which results in exactly the problems discussed in this thread. Often DO calls will wind up wrapped in an API that just does a @try/@catch around the call and returns success/failure, for exactly this reason. _______________________________________________ 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
