i am using the following code to catch an error when ind.row is not a valid value or sometimes it becomes nil
#try {
if(ind.row<[[treeNode flattenElements] count])
{
[self.mTableView scrollToRowAtIndexPath:ind atScrollPosition:UITableViewScrollPositionTop animated:YES];
}
}
#catch (NSException *e) {
NSLog(#"%#",e);
}
but when this code executes sometimes this error is occuring
Assertion failure in -[NSIndexPath row], /SourceCache/UIKit_Sim/UIKit-1262.60.3/UITableViewSupport.m:1948`
what may be the reason for this error and why exception is not being handled
Assertions in iOS don't throw exceptions, so you can't catch them.
You are going to need to figure out what's wrong with your call to -row. My first guess would be that "ind" is already freed or something.
You'll have to check the index, generate and raise an exception on you own:NSException Class Reference
+ (void)raise:(NSString *)name format:(NSString *)format, ...
actually it was already catching the exceptions...i had set the flag stop on objc exceptions.when i removed that it catching the exceptions.... as pointed out by #stilesCrisis the ind value was null at the time of this exception..sorry for the trble
Related
I am following the iOS quick start tutorial and I have gotten as far as creating the button to login to SoundCloud but I'm getting this error:
2013-05-01 15:00:44.698 SoundCloudSample[60999:c07] +[SCSoundCloud shared]: unrecognized selector sent to class 0x3a568
2013-05-01 15:00:44.701 SoundCloudSample[60999:c07] * Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[SCSoundCloud shared]: unrecognized selector sent to class 0x3a568'
* First throw call stack:
(0x192a012 0x174fe7e 0x19b52ad 0x1919bbc 0x191994e 0x2ad0 0x17507cf 0x1757a0d 0x174eaeb 0x174ee22 0x17610e1 0x1763705 0x8c02c0 0x8c0258 0x981021 0x98157f 0x9806e8 0x8efcef 0x8eff02 0x8cdd4a 0x8bf698 0x1da7df9 0x1da7ad0 0x189fbf5 0x189f962 0x18d0bb6 0x18cff44 0x18cfe1b 0x1da67e3 0x1da6668 0x8bcffc 0x1f0d 0x1e35)
libc++abi.dylib: terminate called throwing an exception
(lldb)
- (IBAction) login:(id)sender {
SCLoginViewControllerCompletionHandler handler = ^(NSError *error) {
if (SC_CANCELED(error)) {
NSLog(#"Canceled!");
} else if (error) {
NSLog(#"Error: %# ", [error localizedDescription]);
} else {
NSLog(#"Done");
}
};
[SCSoundCloud requestAccessWithPreparedAuthorizationURLHandler:^(NSURL *preparedURL){
SCLoginViewController *loginViewController;
loginViewController = [SCLoginViewController loginViewControllerWithPreparedURL:preparedURL completionHandler:handler];
[self presentModalViewController:loginViewController animated:YES];
}];
}
I'm not sure exactly what I'm doing wrong since I followed the tutorial.
I'm also confused about the client_id, secret, and redirect URI.
Here is the code for that:
- (void) initialize {
[SCSoundCloud setClientID:#"98e77c3e4da0cc49f2f8e58f278bb813" secret:#"b8311d06a82a8c824b64b8a719479cda" redirectURL:[NSURL URLWithString:#"http://soundcloud.com/connect?client_id=98e77c3e4da0cc49f2f8e58f278bb813&redirect_uri=evesdropmusic://oauth"]];
}
Maybe I overlooked something...
I have found the solution to the problem!
Apparently I think I found a bug in the newest version of XCode.
on the "Other Linker Flags" under the Targets section -- Build Settings, I found that even though I entered the "-ObjC, -all_load", XCode decided not to save those credentials.
The fix is to enter the flags with the (+) - click on them again, then if they go away, enter it again. It should save this time. Sometimes this doesn't occur. I'm not sure why my entries do not remain.
Once I added these again, this fixed the issue.
I have a method that has several parts that can throw an exception. If one of these parts fail, I would like the cleaning method to run. I am thinking about using the try/catch directive.
My question is: will I have to use one directive for every line of code that can throw an exception or can I simply include the whole method in a block like this?
#try {
[self doStuff];
// doStuff has several passages that could throw an exception
}
#catch (NSException * e) {
[self cleanTheWholeThing];
}
In this case it is not important to me which line generated the problem. I just need the method to run successfully or do other stuff in case it fails.
thanks
If you can, avoid exceptions. Even Apple recommends to avoid them:
Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications.
See also their Error Handling Programming Guide (it's marked as being Mac related but is equally valid for iPhone, the same concepts apply).
The reasons for avoiding exceptions are that I know of are:
They are slower than reporting via NSError and an out-pointer.
They can result in memory leaks if you aren't very careful. Some memory leaks due to exceptions cannot be avoided at all (in non-GC environments).
You might forget to catch them, and then your app crashes.
In general, exceptions in Objective-C are used for really exceptional problems that are often unrecoverable. They are almost never used in area where you expect something can go wrong (like network communication; the NSURLConnection methods do not throw exceptions for this reason but export an NSError). This may be different from other languages where exceptions are used more often. In the projects I've been working on I had only once the need to catch and handle an exception (can't remember which, though).
Instead, you should do something like this:
// Returns YES when successful.
- (BOOL)doSomething:(NSError **)outError
{
// ...
if (someErrorOccurred) {
if (outError) {
outError = [NSError
errorWithDomain:#"MyErrorDomain"
code:123
userInfo:nil
];
// Or maybe even use your own NSError subclass
return NO;
}
}
// ...
// Operation was successful.
return YES;
}
You can certainly have multiple lines in your try block. Example:
#try {
if (managedObjectContext == nil) {
actionMessage = #"accessing user recipe library";
[self initCoreDataStack];
}
actionMessage = #"finding recipes";
recipes = [self recipesMatchingSearchParameters];
actionMessage = #"generating recipe summaries";
summaries = [self summariesFromRecipes:recipes];
}
#catch (NSException *exception) {
NSMutableDictionary *errorDict = [NSMutableDictionary dictionary];
[errorDict setObject:[NSString stringWithFormat:#"Error %#: %#", actionMessage, [exception reason]] forKey:OSAScriptErrorMessage];
[errorDict setObject:[NSNumber numberWithInt:errOSAGeneralError] forKey:OSAScriptErrorNumber];
*errorInfo = errorDict;
return input;
} #catch (OtherException * e) {
....
} #finally {
// Any clean up can happen here.
// Finally will be called if an exception is thrown or not.
}
And a link to practical use of exceptions:
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Exceptions/Tasks/HandlingExceptions.html
Its completely alright to enclose the method call with try-catch block.
If you don't care which line caused the exception you can enclose the entire function in a try/catch block.
For example, assume that f1(), f2() or f3() can throw an exception in this code:
try {
f1();
f2();
f3();
}
catch( ... ) {
...either f1, f2 or f3 threw an exception - don't know which
}
You can include the whole method body in your try block.
In your catch part you can have multiple catch blocks to handle different types of exceptions:
#catch (NSException * e) {
....
}
#catch (OtherException * e) {
....
}
#finally {
NSLog(#"finally");
}
so you could also discern exactly which line failed based on the specific exception raised, if you ever need it.
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Exceptions/Tasks/HandlingExceptions.html
You can include the whole method body in your try block.
I'm currently using Facebook C# SDK v4.2.1 and I'm trying to post something onto the user wall. It worked fine until I got an FacebookOAuthException (OAuthException) Error validating access token. error and I can't catch that exception and it crashes my app.
I'm using this call FacebookApp.ApiAsync("/me/feed", ...). Because it happens async I'm not sure where I have to put my try-catch block to catch that error but with no success
This is what I'm using:
private void shareFBButton_Click(object sender, System.Windows.RoutedEventArgs e)
{
// ... code for preparing strings to post ...
try
{
// setup FacebookApp and params ...
app.ApiAsync("/me/feed", args, HttpMethod.Post, (o) => {
if (o.Error != null)
{
Debug.WriteLine("ERROR sharing on Facebook: " + o.Error.Message);
}
else
{
Debug.WriteLine("FB post success!");
}
}, null);
}
catch (Exception ex)
{
Debug.WriteLine("ERROR sharing on Facebook: " + ex.Message);
}
}
So can someone tell me where I have to put my try-catch block, so I can catch the OAuthException?
EDIT:
After further investigation, the FacebookOAuthExcpetion is thrown from Facebook C# SDK after the SDK catches WebException and FacebookApiException. For further information look at "Pavel Surmenok" his answer. That is exactly what is happening.
As of the moment the only solution for catching FacebookApiException (base class of all Facebook SDK exceptions) is to catch it in App.UnhandledException method. Check type of e.ExceptionObject and if it is a FacebookApiException set e.Handled to true and the app won't exit itself anymore.
I found a solution for my problem. Maybe I should rephrase my question.
"How to catch an exception which occurred on a background thread?"
Which is exactly what is happening in my original question. An exception is throw inside the Facebook C# SDK on a background thread because Api calls are executed asynchronously.
Maybe most of you already know this, but I didn't because I'm new to WP7 development.
Solution:
In App.UnhandledException event handler, just set the e.Handled flag to true. Then the app won't exit ifself.
private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
{
// catch Facebook API exceptions
// if handled is set to true, app won't exit
if (e.ExceptionObject is FacebookApiException)
{
e.Handled = true;
// notify user of error ...
return;
}
if (System.Diagnostics.Debugger.IsAttached)
{
// An unhandled exception has occurred; break into the debugger
System.Diagnostics.Debugger.Break();
}
}
Not sure if this is the right way to catch an API exception, but works fine for now.
I've reproduced this trouble. As I can see, the exception is generated in FacebookApp.ResponseCallback method. It contains "try" block with two "catch" sections (one for FacebookApiException and one for WebException). In the end of each "catch" sections the exception is being rethrown and is never been handled (that's why your app crashes). So, the debugger says you about this (rethrown) exception.
Later in "finally" section they create FacebookAsyncResult with reference to this exception in the property "Error".
I think that your solution (to handle this exception in App.UnhandledException) is the most appropriate one.
By the way, it's interesting, why SDK developers decided to rethrow exceptions in FacebookApp.ResponseCallback.
The debugger usually does a good job of indicating where the exception came from. In the debugger, you can examine the exception details and look at the nessted InnerExceptions to find the root cause.
That said, if the exception is thrown from within the app.ApiAsync call, then the catch handler that you already have would catch any exceptions. By the looks of things in the SDK (I've only looked briefly), there are certain circumstances where exceptions are caught and forwarded to the callback in the Error property, which you are also checking.
By looking at the SDK code, it would seem that the exception being thrown is actually the FacebookOAuthException; is that the case? If that is the case, then it looks like this exception is never provided to the callback, but always thrown.
If you can give more details about exactly what the exception type is and where it's thrown/caught, I might be able to give a more useful answer.
Trying to catch the exception in App.UnhandledException does not work as it is on a different thread. But you can play with the 'error reason' property from authResult before doing the query and so you will avoid to have the exception thrown.
private void FacebookLoginBrowser_Navigated(object sender, System.Windows.Navigation.NavigationEventArgs e)
{
FacebookAuthenticationResult authResult;
if (FacebookAuthenticationResult.TryParse(e.Uri, out authResult))
{
if (authResult.ErrorReason == "user_denied")
{
// do something.
}
else
{
fbApp.Session = authResult.ToSession();
loginSucceeded();
}
}
EDIT: Issue has been solved(partially):It is a simulator bug. I've compiled and tested this on two devices with iOS 3.1.3 and 4.0. The exception was handled correctly. Be careful, the simulator is your enemy!
this is driving me crazy. I don't know how to enable exception handling in my project. Look at the code and debugger output below.
My Goal is to catch the exception, not correcting the code so the exception is handled and the app doesn't crash.
I'm using XCode 3.2.3, iPhone SDK 4 final. I have just created a simple view based iPhone App to test this.
I have looked in my project settings and yes the switch "Enable Objective-C Exceptions" is checked. I am using GCC 4.2.
When I look at the build process in detail the compiler flag -fno-objc-exceptions is not within the list of arguments!
What am I missing here?
Thanks in advance
Nick
NSArray * foo = [[NSArray alloc] init];
#try {
NSLog(#"trying...");
[foo objectForKey:#"yeah"];
}
#catch (NSException * e) {
NSLog(#"catching %# reason %#", [e name], [e reason]);
}
#finally {
NSLog(#"finally");
}
leads to
trying...
-[__NSArrayI objectForKey:]: unrecognized selector sent to instance 0x5d5f780
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSArrayI objectForKey:]: unrecognized selector sent to instance 0x5d5f780'
*** Call stack at first throw:
(
0 CoreFoundation 0x02393919 __exceptionPreprocess + 185
1 libobjc.A.dylib 0x024e15de objc_exception_throw + 47
2 CoreFoundation 0x0239542b -[NSObject(NSObject) doesNotRecognizeSelector:] + 187
3 CoreFoundation 0x02305116 ___forwarding___ + 966
4 CoreFoundation 0x02304cd2 _CF_forwarding_prep_0 + 50
...
)
terminate called after throwing an instance of 'NSException'
Whether the catch nor the finally block is ever reached.
Quote from How do I catch global exceptions? :
"objc_exception_throw is not an exception. It is the function that throws Objective-C exceptions. Similarly, EXC_ARITHMETIC is not an Objective-C exception; it is a Mach (kernel) exception, meaning that your app tried to do something completely invalid. – Peter Hosey May 14 at 9:14"
That thread does have a link to a solution for your problem though, it appears. The link goes to http://www.restoroot.com/Blog/2008/10/20/crash-reporter-for-iphone-applications-part-2/ which looks a little risky, but if it works, it might be worth it for you.
There are bug reports related to this, e.g.: http://www.openradar.me/8081169 (posted earlier this month)
(Updated to summarize information from comments below.)
If I understand your problem right.
Your Try/ catch block is working correctly.
It is trying to run your code, and catches an error.
You need to decide what to do when it catches an error and code for it within the block.
I normally do that in the CATCH part. As the finally bit will execute regardless of an exception or not being thrown.
Your example code is catching the NSException exception but not the one being thrown, NSInvalidArgumentException. You might have better luck if you look for that specific exception.
NSArray * foo = [[NSArray alloc] init];
#try {
NSLog(#"trying...");
[foo objectForKey:#"yeah"];
}
#catch (NSInvalidArgumentException *e) {
NSLog(#"Invalid argument called.");
}
#catch (NSException * e) {
NSLog(#"catching %# reason %#", [e name], [e reason]);
}
#finally {
NSLog(#"finally");
}
I don't have any way of testing it myself right now, though.
See http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocExceptionHandling.html for more information.
I'm trying to use NSAssert throughout my iPhone app so that if an unexpected condition occurs, the application fails-fast and crashes with a meaningful message in the crash log.
This works fine if the failing NSAssert is on the main thread, as it raises NSInternalInconsistencyException by default which is uncaught and stops execution. But I'm also doing processing in background threads, in which case the NSAssert just aborts the thread, but the programming keeps running.
My current solution is to catch and rethrow the exception in the main thread (in this case, NSOperation's main method):
- (void)main {
#try {
int x = 14;
...
NSAssert1(x > 20, #"x should be greater than 20, was %d", x);
...
}
#catch (NSException *e) {
[e performSelectorOnMainThread:#selector(raise) withObject:nil waitUntilDone:YES];
}
}
Is there a better way? Perhaps using a custom NSAssertionHandler?
I know I could just use C's assert with a static annotation:
assert(x > 20 && "x should be greater than 20");
But this doesn't allow me to show what the actual failing value of x is.
You can replace the NSAssert with a test code followed by an exception raise. This way, if the assertion failed, an exception will be thrown, catched by the #catch block and re-raised on the main thread.
Note: You can even define a C macro, in order to provide a compact form.