I have a model object that represents a triangle. There are a handful of init methods taking different combinations of parameters that are known. Then it solves for the remaining values (lengths of sides and angles). Currently I have the initializer return nil if the given parameters are nil or out of proper ranges for this triangle type. However to give proper feedback to the user the controller object has to also check for improper input values like angle > 90 deg and the like. This stinks to me as these rules should be defined once in just the model. So my thought is to have an NSError object that gets set to string that the controller should show to the user. I’m just not sure the best way to convey this to the controller. Should my init method return this NSError instead of the Triangle instance if an error occurs? This seems wrong. Or do I pass a pointer to the NSError object as a parameter to the init, and populate it if an error occurs? If I do this do I still return nil from the init for the triangle object since its unusable or do I just partially init the triangle and return that?
Share
You should follow the same convention that other Cocoa objects use, as described in Apple’s Error Handling Programming Guide:
NSError**as the last parameter to the method.NULL, populate it with anNSErrorobject and returnnil.initmethod, you should also[self release]before returningnil(unless you’re using ARC).