The Lithium iOS Library is now available...
If you’re a developer, you can now use rich functions available in Lithium’s iOS Library to connect to Lithium communities. This means you can create and enhance iPhone and iPad apps with Lithium com...
Forum Discussion
Hi Ash,
For the NSErrors request, we don't have standard error codes to provide; so at best, you'd have an NSError object with a localized error string inside its userData hashmap. Does it make sense to just send back the error string in this case? Or do you still want it wrapped in an NSError object?
Jeff
Hi Jeff
I think it would be better in the long run of your framework if you implement this as an NSError since you could start adding more relevant information to log/debug errors. You will also more easily be able to forward http status codes and any error codes that are being raised through service calls as you build more features.
Also, the error codes dont have to be standardised. As long as the domain and error code you pass through (which would make the combination unique) can help us talk with Lithium to troubleshoot, it would then be extremely valuable information.
There will be errors that we would want to pass on to the user (for example authentication or even registration related codes) and likewise errors that we would manage internally. Therefore standardise your framework to always use NSErrors and you would gain flexibility in making changes downstream.
-Ash
