views:

94

answers:

2

Hey all I'm using a MPMoviePlayerController and trying to catch my exception when there is no movie present.

movies = [movieDictionary objectForKey:@"movieID"];

NSLog(@"callVideoSetting");
CGRect playfram = CGRectMake(0, 0, 320, 500);

stopButton = [UIButton buttonWithType:UIButtonTypeCustom];
[stopButton setFrame:playfram];
[stopButton addTarget:self action:@selector(stopVideo:) forControlEvents:UIControlEventTouchUpInside];

NSURL *movie = [NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:movies ofType:@"m4v"]];
//path for resource moet id worden 
theMovie = [[MPMoviePlayerController alloc] initWithContentURL:movie];
[theMovie setOrientation:UIDeviceOrientationPortrait animated:NO];

Now I wish to catch the exception when there is nothing behind movies.

-[NSURL initFileURLWithPath:]: nil string parameter'

I know I should have a try catch block.. But I've never handled exceptions in objective-c.

+5  A: 

Simply use a variable:

NSString * path = [[NSBundle mainBundle] pathForResource:movies ofType:@"m4v"];

if (!path) {
  // error handling
}

NSURL *movie = [NSURL fileURLWithPath:path];
Philippe Leybaert
Just saw this after I replied below. The above is generally a better way to handle this. Exceptions are more or less discouraged in obj-c
pzearfoss
Exceptions should be discouraged for **anything**, except for situations that are really *exceptional*, like power failures, lost network connections, out of memory, etc.. They should never be used for "normal" application logic (IMNSHO).
Philippe Leybaert
Exceptions serve a function that generally isn't really needed in ObjC. Their big advantage in C++ is that they make memory management much easier. But ObjC has much cleaner solutions to that (mostly through -autorelease), so they're a very big hammer for a very small problem. At times they're still useful, but not for something as simple as a nil pointer. If they were as powerful as Java exceptions (compiler-enforcement of catch for all throwable exceptions), they might be more useful in normal code, but they're not, so they're not. ObjC's dynamic runtime makes that kind of enforcement hard.
Rob Napier
@Philippe But almost all programs will encounter several kinds of exceptional situations (and a nil pointer in the code above may very well be exceptional). Exceptions as a language construct are a good solution for managing that exceptional code (which can get in the way of normal code). They just don't work very well in ObjC because they're far too expensive for the value they give (which isn't much in ObjC).
Rob Napier
thank you all for your explanations really appreciate it.
jovany
A: 

General try/catch block

@try
{
  // your call that throws the exception
}
@catch (NSException *e)
{
  // handle the exception
}
pzearfoss
Neither Mac OS X nor the iPhone use exceptions to handle errors of this nature. An exception is thrown for fatal errors only in all but very rare situations. I.e. once an exception is thrown, it is too late to recover.
bbum