As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm having issues with one of the practise questions given by my teacher. I don't even understand what the question is asking, so any help would be appreciated.
"To practise methods and classes write a class with a method that throws an exception. Write another method for the class that invokes the previous method, catches and handles the exception. Test your code using a main function."
The only thing I understand is testing it with the main function. Any help would be greatly appreciated, thanks.
what you are looking for is a method that contains a try/catch statement
#try {
//do something
}
#catch (NSException *exception){
//do something if the code in the try failed
//OR
#throw exception; //this will make the method called "above" this method handle the exception (eg a method calling another method, that fails, passes the exception back to the top level one)
}
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The syntax is legal. It'll save you about 2 seconds every time you alloc/init an object. Do you think this could be a new trend?
Again,
NSObject *obj = NSObject.alloc.init;
[NSObject new];
Saves even more and doesn't cause any religious wars.
Yes, it saves a few keystrokes, but I doubt it will catch on. See this blog post for a number of cases where using dot notation on methods rather than properties will not work. I think most people view this as a side effect of ObjC2.
Furthermore, I don't think it enhances readability at all. As soon as you want to send a message with an argument, you have to revert back to the original syntax.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am trying to understand how the AFNetworking Framework works. But there is little detail I do not understand.
I wrote a subclass of AFHTTPclient than made it a singleton class and added a Initializer that does the following :
- (id)initWithBaseURL:(NSURL *)url {
self = [super initWithBaseURL:url];
if (self) {
[self registerHTTPOperationClass:[AFJSONRequestOperation class]];
}
return self;
}
I got this code from a tutorial I found on the internet, but I do not understand why I have to register my class for JSONRequestOperation if I want to get JSON Data back? What exactly happens under the hood if I am doing so? What does the registerHTTPOperation class exactly do?
PS: Is there a good documentation with examples and in-depth explanations of AFNetworking somewhere on the internet?
The registerHTTPOperationClass: on AFHTTPclient will use the class set to handle you request when using the getPath and postPath methods.
In your given example, the HTTPRequestOperation is set the the AFJSONRequestOperation, which means that all request to the server will be done with an instance of AFJSONRequestOperation. The AFJSONRequestOperation will try and parse the result from the server with the NSJSONSerialization class.
If you server responds with XML you should set the HTTPRequestOperation to AFXMLRequestOperation for example.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I seem to be coming across a lot of variable (boolean) for some Options that control whether something will be done, like:
GiveWarningEnabled
FeedbackEnabled (will provide feedback)
These will be used a lot and I"m trying to think of a good pre/suf fix that will indicted it's Boolean. My best thought so far was Enabled.
Perhaps: Will?
WillGiveWarning (or WillWarn)
WillGiveFeedback?
often times "is" will be used, such as isPlaying or isWifiEnabled.
Will, should, can, and does are also good ones to use because they express conditions. A verb such as "give", like the one you listed, seems to better fit a function declaration since it is performing an action.
I usally prefer flag.
Example:
warningFlag,
feedbackFlag.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Imagine an ordinary UIViewController subclass. We want to do "setup stuff" to be preformed before -viewDidWhatever, but the problem is that there are three methods that could possible be called, either -initWithNibName, -initWithCoder or simply -init depending on how it is created.
The solution would be to create -setup to be called from all these three, but I'm a bit unsure about the name. My question to you is: is there any standard naming of this method?
I have commonly named it -setup myself when doing this.
Depending on what you want to do, you could put it in + (void)initialize, which is inherited from NSObject and will automatically be called before the class receives its first message.
Have a look here: Apple Developer Library: NSObject Class Reference
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
To better understand ARC I'm looking for example code that compiles perfectly with ARC enabled , but crashes at runtime. Ie the common pitfalls that may be overlooked and can cause you a debugging nightmare if you've never encountered that issue before.
Real life examples tuned down to the minimum code that reproduces the issues would be very helpful. In particular if the ARC code is interfacing with C or C++ code.
Quick example of the many I was thinking along the same lines as bbum.
Casting from CF... to NS... confuses ARC if done incorrectly for example:
CFArrayRef *supportedInterfaces = CNCopySupportedInterfaces();
NSArray *interfaceNames = (__bridge_transfer NSArray *)supportedInterfaces;
CFRelease(supportedInterfaces);
Would over-release supportedInterfaces since __bridge_transfer retains the NSArray while releasing the CFArrayRef. In this case either don't use the CFRelease() or use plain __bridge.