This is considered typical
- (id)init {
self = [super init];
if (self) {
// <#initializations#>
}
return self;
}
Not really.
with:
self = [super init];
you are calling your superclasses init method, which only in RARE cases will return nil. (like if the system has low memory, which you have other problems).
if(self)
this will not go through if no instance is returned (it is nil) so there is no need for the else.
the old way was
if((self = [super init))
{
// do initialization
}
return self
EDIT: Was reading the Cocoa Fundementals guide and found this under Error Handling:
If the error encountered in a method implementation is a system-‐level or Objective-‐C runtime error, create and raise an exception, if necessary, and handle it locally, if possible. In Cocoa, exceptions are typically reserved 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 errors with exceptions when an application is being created rather than at runtime. Cocoa predefines several exceptions that you can catch with an exception handler. For information on predefined exceptions and the procedure and API for raising and handling exceptions, see Exception Programming Topics.
For other sorts of errors, including expected runtime errors, return nil, NO, NULL, or some other type-‐suitable form of zero to the caller. Examples of these errors include the inability to read or write a file, a failure to initialize an object, the inability to establish a network connection, or a failure to locate an object in a collection. Use an NSError object if you feel it necessary to return supplemental information about the error to the sender. An NSError object encapsulates information about an error, including an error code (which can be specific to the Mach, POSIX, or OSStatus domains) and a dictionary of program-‐specific information. The negative value that is directly returned (nil, NO, and so on) should be the principal indicator of error; if you do communicate more specific error information, return an NSError object indirectly in a parameter of the method.