Timeline for success:/failure: blocks vs completion: block
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 7, 2017 at 4:21 | comment | added | maddy | completion blocks are great in case in future you have to nested some code. Success, failure way will be creating lot of duplicate code. | |
| Jan 20, 2016 at 8:14 | comment | added | Travis | @Boon One reason I see the single handler as being more generic is for cases where you would prefer the callee/handler/block itself determine if an operation succeeded or failed. Consider partial success cases where you possibly have an object with partial data and your error object is an error indicating that not all data was returned. The block could examine the data itself and check to see if it is sufficient. This is not possible with the binary success/fail callback scenario. | |
| Oct 28, 2014 at 1:36 | comment | added | Boon | I don't understand how completion handler is more generic. Completion basically turns multiple method params into one - in the form of block params. Also, does generic mean better? In MVC you often times have duplicate code in view controller as well, that's a necessary evil due to separation of concerns. I don't think that's a reason to stay away from MVC though. | |
| Jan 30, 2013 at 19:53 | vote | accept | Jeffery Thomas | ||
| Jan 23, 2013 at 19:07 | review | First posts | |||
| Jan 23, 2013 at 19:23 | |||||
| Jan 23, 2013 at 19:05 | comment | added | user79302 | Yeah, and if block is not in-place, but is passed as argument to your controller, you have to toss two blocks around. This may be boring when callback needs to be passed through many layers. You always can split/compose it back, though. | |
| Jan 23, 2013 at 19:00 | comment | added | Jeffery Thomas | Yeah, I can see that. If -task… could return the object, but the object is not in the correct state, then you would still need error handling in the success condition. | |
| Jan 23, 2013 at 18:55 | comment | added | user79302 | Can't comment on original question... Exceptions are not valid flow control in objective-c (well, cocoa) and should not be used as such. Thrown exception should be catched only to terminate gracefully. | |
| Jan 23, 2013 at 18:52 | history | answered | user79302 | CC BY-SA 3.0 |