Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What are best practices for error handling when writing an API for the iphone?

We are writing an API for iphone developers and we don't know what the best practice is for exception handling. We looked into NSError, standard POSIX way, NSException

What is the convention that most APIs use? Which is the most "Objective-C friendly"?

like image 796
Ovi Tisler Avatar asked Mar 30 '10 15:03

Ovi Tisler


People also ask

How do you handle errors in API?

The simplest way we handle errors is to respond with an appropriate status code. Here are some common response codes: 400 Bad Request – client sent an invalid request, such as lacking required request body or parameter. 401 Unauthorized – client failed to authenticate with the server.

How should a developer handle errors in a given IOS application?

You can propagate the error from a function to the code that calls that function, handle the error using a do - catch statement, handle the error as an optional value, or assert that the error will not occur.

What is an API error?

Generally speaking, it means one of two things — something was so wrong in your request or your handling that the API simply couldn't parse the passed data, or the API itself has so many problems that even the most well-formed request is going to fail.


2 Answers

From the Introduction to Exception Programming Topics:

Important: You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime.

...

Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications. For further information, see Error Handling Programming Guide For Cocoa.

So as I understand it, only use exceptions when something is fatally wrong. Otherwise, use NSError objects.

like image 144
Dave DeLong Avatar answered Oct 20 '22 16:10

Dave DeLong


+1 for NSError.

I forget where in the Apple docs I read this, but I also recall them encouraging the coding philosophy of "try first, then check for errors," as opposed to "check for validity, then do the operation." For example, instead of seeing if the network is available before using it, just try to use it and respond to an error if/when you get one back.

I agree with this philosophy for many use cases because (a) it moves validity-checking to the moment of action, so in a sense it's more accurate, and (b, subjective) it's more fun to work with code in this pattern.

To summarize, the suggestion is to use NSError, and to provide immediate feedback with NSError** parameters that accept NULL, to be very friendly to your API-users! This pattern is also established in several places in Cocoa/Touch; for example the NSString method writeToFile:atomically:encoding:error:.

like image 31
Tyler Avatar answered Oct 20 '22 16:10

Tyler