Fairly simple question:
I have an init method on my class that has the potential to go wrong. If it does, I plan to "return nil", but I would also like to return an error. Is it bad practice to have an NSError** parameter to an init method? My method declaration would look like this:
- (id) initWithArgs:(NSString*) args andError:(NSError**)error;
Many thanks,
Nick
It's unusual, but I don't think it's necessarily a bad practice. I'd name the second part of the method just "error" instead of "andError:", though. You don't need to connect the parts of a method name with 'and', and in this case it also gives the impression that the error is being used to initialize the object. Just make it:
- (id) initWithArgs:(NSString*) args error:(NSError**)error;
Also, don't forget to release the allocated object if you plan to return something else (like nil):
- (id) initWithArgs:(NSString*) args error:(NSError**)error
{
if ((self = [super init])) {
if (canInitThisObject) {
// init this object
}
else {
[self release];
self = nil;
if (error != nil) {
*error = [NSError errorWithDomain:someDomain code:someCode: userInfo:nil];
}
}
}
return self;
}
Related
I use a sinlgeton in my application for managing data that is available to the whole application, which accessed via:
static MMProductManager *sharedInstance = nil;
+(MMProductManager*)SharedInstance {
dispatch_once( &resultsToken, ^(void) {
if ( ! sharedInstance ) {
sharedInstance = [[MMProductManager alloc] init];
}
});
return sharedInstance;
}
Everything is working as expected.
In Objective C, there does not seem to be a way to hide any object's init method, and in my case having more than instance of MMProductManager would lead to data being duplicated (in the best case scenario).
What I would like to do is guard against instantiating more than one instance. Other languages seem to have this feature; i.e. marking certain methods/classes as private. I am thinking of implementing something along like:
-(id)init {
// guard against instantiating a more than one instance
if ( sharedInstance )
return sharedInstance;
if ( (self = [super init]) ) {
self->_resultsQueue = dispatch_queue_create( kMMResultQLAbel, NULL );
self->_initialized = FALSE;
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(handleNotification:)
name:UIApplicationDidReceiveMemoryWarningNotification
object:0];
[self initialize];
}
return self;
}
Does this approach seem reasonable?
What would happen in the case of someone allocating this class, then calling the init described above? Would it be reasonable to override +(id)alloc? If so How would I go about doing that?
I know the convention of exposing a SharedInstance method is an implicit message to other developers to go through this method, but I would like a bit more control if possible.
You don't want to override - init (if not for some other reason) - - init is not the method that creates the instance. You want to override + alloc for this:
#implementation SingletonClass
+ (id)alloc
{
static id instance = nil;
if (instance == nil) {
instance = [super alloc];
}
return instance;
}
#end
This way you can actually prevent (almost) completely creating multiple instances of SingletonClass.
(Unless somebody falls back to calling
id trickyDifferentInstance = class_createInstance(objc_getClass("SingletonClass"), 0));
but that's very unlikely.)
Following is my code（with some unrelated thing omitted):
#implementation HomeSceneController
...
#synthesize options = _options; // _options is a NSArray object with 4 elements
- (id)init
{
if (self = [super initWithNibName:#"HomeScene" bundle:nil]) {
_currentOptionIndex = 0;
// Following code add two key event observations, when up arrow or down arrow key is pressed, the corresponding function will be fired.
[self addObservation:_KEY_UPARROW_ selector:#selector(UpArrowPressHandler)];
[self addObservation:_KEY_DOWNARROW_ selector:#selector(DownArrowPressHandler)];
}
return self;
}
- (void)loadView {
[super loadView];
// init _options
_options = [NSArray arrayWithObjects:
_localGameOption,
_networkGameOption,
_controlSettingOption,
_quitOption,
nil];
[self selectOption:_localGameOption];
}
....
// in these two functions, _options become nil! I don't know why...
- (void)UpArrowPressHandler {
if (_currentOptionIndex > 0) {
[self deselectOption:_options[_currentOptionIndex]];
_currentOptionIndex--;
[self selectOption:_options[_currentOptionIndex]];
}
}
- (void)DownArrowPressHandler {
if (_currentOptionIndex < 3) {
[self deselectOption:_options[_currentOptionIndex]];
_currentOptionIndex++;
[self selectOption:_options[_currentOptionIndex]];
}
}
#end
when I press up arrow key, the UpArrowPressHandler function is fired. However, the problem is, the _options array become nil.
Can anyone tell me why and how to fix it?
//===========================================================================================
Additional problem:
In the following program:
import "Deep.h"
#implementation Deep
- (id)init {
if (self = [super init]) {
_name = #"Deep";
}
return self;
}
- (void)test {
NSLog(_name);
}
#end
The test method can correctly print "Deep" when I call it somewhere else.
However, according to #ATaylor's explanation, _name should be released.
So, where is my problem?
That's because _options is getting assigned an autoreleased object, which gets released once you leave the method it was called from.
Try assigning it to 'self.options', which will (most likely) call 'retain' on the object, or call 'retain' explicitly.
Once more in code:
Either use:
self.options = [NSArray ...];
Or:
_options = [[NSArray ...] retain];
Please don't forget to release your 'options', once you're done with it, either by:
self.options = nil;
or:
[_options release];
Please only go for ONE of these options, because otherwise you'll get weird behaviour with the retain count.
You see, Apple gives us a number of 'convenience functions', which return autoreleased objects, meaning we don't have to bother with their release.
As a general rule of thumb:
Call release for every alloc/retain you call yourself.
To answer the second question:
_name = #"Deep";
is an assignment to a variable, equivalent to 'const char *_name = "Deep";' from C.
There is no need to release that, for the simple reason, that you didn't create or retain it. (No new, No alloc, no retain, no copy).
The object will not get autoreleased either, because you didn't call any sort of method, which would cause the variable to be autoreleased.
Also, see this answer, which deals with the exact problem.
Just for clarification, to get a string, there are three types of methods.
NSString *someString;
someString = #"MyString"; //No retain, no release, static String.
someString = [NSString stringWithFormat...]; //Autoreleased object, disappears after the method expires.
someString = [[NSString alloc] initWithFormat...]; //Alloced object, must be released.
Here is the code :
#implementation Accumulateur
// Constructor
- (id) init
{
return ([self initWithTotal:0]);
}
- (id) initWithTotal:(int)aTotal
{
AccumulateurMoyen *ac;
if ((ac = [[AccumulateurMoyen alloc] init]) == nil)
{
[self release];
return (nil);
}
return ([self initWithTotal:aTotal andAccumulateurMoyen:ac]);
}
- (id) initWithTotal:(int)aTotal
andAccumulateurMoyen:(AccumulateurMoyen *)aAcMoyen
{
if (self = [super init])
{
[aAcMoyen retain];
[acMoyen release];
acMoyen = aAcMoyen;
total = aTotal;
}
return (self);
}
#end
The problem is here : if ((ac = [[AccumulateurMoyen alloc] init]) == nil)
As I redefined init, the init called is mine and not that of NSObject...
I dont have idea, how i can do that correctly (AccumulateurMoyen is subclass of Accumulateur)
Thx you
You have probably undesired recursion there: [[AccumulateurMoyen alloc] init] tries to create new AccumulateurMoyen but that results in nested initWithTotal: which again tries to create another AccumulateurMoyen instance etc.
I.e. your code tries to create Accumulateur which has member acMoyen set to new instance of AccumulateurMoyen, which again has its acMoyen set to another new instance of AccumulateurMoyen etc.
You must to break the endless recursion. E.g. in initWithTotal:, replace the line
if ((ac = [[AccumulateurMoyen alloc] init]) == nil)
with
if ((ac = [[AccumulateurMoyen alloc] initWithTotal:0 andAccumulateurMoyen:nil]) == nil)
I.e. the nested AccumulateurMoyen will have its member set to nil.
Sorry but I think you have a structural problem here. Why your super class need to have an reference to a class that extend it? I think your best option to it is think again how your class structure will be.
But in your subClass you can change the init method to so your problem will disappear.
(id)init {
return ([NSObject init]);
}
This is currently what I have for my init,
- (id)init
{
self = [super init];
if (self) {
self.url = [[NSURL alloc] init];
self.blurb = [[NSString alloc] init];
self.author = [[NSString alloc] init];
}
return self;
}
It does nothing, but I have another method called initWithObject: that will use its argument to fill up the instance variables url, blurb, and author. I don't know what I should be doing with this init. Should I throw an exception? What other options do I have?
If you want to override your standard -init method you could either return nil (if you do not want -init to be used) or do:
- (instancetype)init
{
return [self initWithObject:nil];
}
If you want to stop the use of -init completely you can tag it as an unavailable attribute or use NSAssert:
// .h
// ...
- (instancetype)init UNAVAILABLE_ATTRIBUTE;
// ...
// .m
- (instancetype)init
{
NSAssert(NO, #"This method should not be used");
return nil;
}
You can use either UNAVAILABLE_ATTRIBUTE or NSAssert(), but if you use UNAVAILABLE_ATTRIBUTE you need some kind of implementation of -init, even if it just returns nil.
You don't have to have a plain init—you can simply have your initWithObject: method. If you're doing any basic setup that will remain the same 80% of the time, or if you have some common code in all your initializers, you can override init, but you are not required to.
Also consider changing your initWithObject: name to be more specific, to something like initWithPost: (I'm assuming this is some kind of blog-entry fetcher based on your ivars) so it's more apparent what object is desired.
I think you misinterpreted what you read. I don't think you would throw an exception. You could; however, leak memory. If your initWithObject: method looks like this:
- (id)initWithObject:(id)obj {
if ((self = [self init])) {
self.url=[obj url];
self.blurb=[obj blurb];
self.author=[obj author];
}
return self;
}
And you would be perfectly fine. You could get an exception if your object was instantiated with -init and you used a variable which was assigned, assuming it was real. So in your subsequent methods be sure to check that the objects exist before using them.
If you made your object with -init rather than -initWithObject this could throw an exception:
- (void)dealloc {
[url release];
[blurb release];
[author release];
[super dealloc];
}
The rule that Apple has established for Cocoa programming is that every class must have one initializer method which is the "Designated Initializer". Every other initializer for the class must call that D.I.* The D.I. itself must call the superclass's D.I. Generally, the initializer with the greatest number of arguments (the one that most completely specifies the state of the new object) is the D.I.
In your case, with the bare init, and initWithObject:, the second would likely be the D.I. You would therefore override init to call initWithObject: with some default argument:
- (id) init {
return [self initWithObject:[Object objectWithURL:[NSURL URLWithString:#"http://www.apple.com"]
blurb:#""
author:#""]];
}
This will result in a sort of dummy object, which is correctly initialized with useless data. (Outside of ARC, be sure to watch the memory management of the default argument(s) -- you want to use an autoreleased/unowned object(s).)
*Sometimes an exception is made for initWithCoder:.
If you have any method that you don't want called and that you don't want your subclass to support, throwing an exception in a Debug build is perfectly reasonable.
What is the proper way of overloading init methods with variable param number? I'm doing it:
- (id)initWithInt:(int)a
{
return [self initWithInt:a andString:nil];
}
-(id)initWithInt:(int)a andString:(NSString*)str
{
self = [super init];
if (self) {
NSLog(#"%# %i",str,a);
}
return self;
}
It works, but the return [self initWithInt:a andString:nil]; does not seem right to me(there is no self at the moment, right?)
No, this is perfectly valid. Self is already setup, the idiom of reassigning self is for a couple of different edge cases (initialization fails, the initializer wants to return a different instance then the one you allocated, etc).