views:

461

answers:

2

Hi all,

I'm curious, how do most of you folks handle errors such as HTTP Forbidden or 5xx type requests from a server? Or say an exception is thrown in one of your UIViewControllers? Do you typically bubble up the error to the App Delegate and handle generic "window" level errors at that point? Do you couple errors directly into the UIViewController? What if you have several UIViewController's which all speak to a common NSURLConnection wrapper, and a connection fails for some HTTP 4xx or HTTP 5xx similar error. Will you typically bubble up the error to App Delegate so it can present a UIAlertView from that portion of the application?

Just wondering what solution you're using for your Mac OSX/iPhone error handling techniques.

Thanks a bunch.

+2  A: 

Your current view controller should be responsible for dispatching any error message and dealing with the result.

The last part is the key here. If you encounter an HTTP error and pass the message up to your app delegate with a "retry" option the response then needs to go all the way back down to the controller. This all gets a bit yucky.

Now you may want to create a common class/view in your app that can deal with all the errors you're likely to encounter, but this should still be presented (in a modal fashion) by the controller that encounters the error and it's this controller that should receive delegated responses.

Andrew Grant
+1  A: 

The controllers may or may not need to know there has been an error in order to properly recover from a network error, but for iPhone development I have found it useful to have a core communications class that understands all the communication going into and out of the system, and when it detects failures issues an alert directly. That way you can prevent an overload of failure notices if a user switches tabs or otherwise moves about the application, and just generate one message so that the user can understand why screens are not updating.

Kendall Helmstetter Gelner