I have a custom View Controller that is a subclass of UIViewController that requires a data object to be set up properly. Without this object, showing the VC doesn’t make any sense.
So I created a custom initialiser that requires this object to be passed as an parameter/argument.
There is also no “default” data object, so there is no point for me to override the inherited init, and implement passing this default data object internally from init to custom init.
Instead I am raising an exception that explains that you need to add an object in the designated custom initialiser instead of using the inherited init method.
However, my colleagues object that I just should return nil in the overridden standard init.
However they are not giving me any proper argument, they only tell me that this is the convention. Which is not an argument for me strictly speaking. I won’t do things just because they are tradition.
Why return nil and why raising a custom exception is wrong?
1
Convention on platforms is important. It’s how you can move from one code base to another with the least effort. New code should be named and should behave as predictibly as possible.
You wouldn’t just have one class in, say, a Java program that uses underscores in its method and variable names rather than camel case. I’m sure you wouldn’t break that rule, but it’s just a convention, too.
Convention plays an even bigger part in Cocoa when you’re using ARC. Method names are used to help manage memory — Apple took a convention and turned it into a rule.
Your exception case is similar. Most Cocoa programmers would not expect a Cocoa program to raise an exception in its init method. The convention is that it returns nil on error.
There is certainly a case for breaking rules and conventions, but you have to be careful and only do it in truely exceptional circumstances. A class with a mandatory property is a pretty common case and not one, I think, that warrants breaking the convention.