NSException raise:format: as the last statement in a method

Question

I have this method:

+ (MHTwitterParser*)createParser:(NSString*)format {
    if ([format compare:@"json"] == NSOrderedSame) {
        return [[MHJsonTwitterParser alloc] init];
    }

    [NSException raise:@"Unknown format" format:@"Unknown format of parser"];
}

Compiler complains that:

Control may reach end of non-void function

It is just a warning, but it does not matter.

Obvious fix for that is to add for example return nil; after the [NSException raise: ....

However, I think it is not needed (and is even misleading for readers), because the exception is thrown, so it is not true that "Control may reach end of non-void function". Or am I missing something ...? Is it only compiler imperfection or there is some considerable reason for this?

The compiler is Apple LLVM compiler 3.1

It's just a method on an object, if I wanted I could swizzle the method to not throw an exception and then my program would reach the end of non-void function... I'm sure there are other more usable reasons — Paul.s, May 01 '12 at 16:41
@Paul.s Thanks Paul. That makes sense and it is valid point. I am curious if somebody will come up with some other explanation. — Ondrej Peterka, May 01 '12 at 16:46

score 12 · Answer 1 · answered May 01 '12 at 17:51

12

Replacing [exception raise]; with @throw exception; is functionally the same thing and will prevent the warning (see: Throwing Exceptions).

answered May 01 '12 at 17:51

Jeffery Thomas

42,202
8
92
117

score 9 · Accepted Answer · edited Feb 05 '15 at 09:38

9

The reason is simple.

For the compiler, the method [NSException raise: ...] is a black box method. It doesn't know that the method will actually raise an exception.

If you compare it with Java or C++, their throw statements are a language feature and the compiler knows exactly what will happen when it finds it. In Obj-C it's different and sometimes it depends on runtime conditions. Consider the following.

NSException* exception = nil;

if (someCondition) {

   exception = [NSException exceptionWithName:...];
}

[exception raise];

The compiler won't know if the exception is really raised or not.

edited Feb 05 '15 at 09:38

answered May 01 '12 at 16:46

Sulthan

128,090
22
218
270

The explanation is really nice, but this is not the accurate answer. The warning is not because compiler doesn't recognizes `NSException` but it can see a non-returning statement at the last line, just after a condition (which may be executed or may not) – geekay Sep 27 '13 at 11:49
@geekay That's not true. If you replace the last statement with something the compiler undestands, e.g. `abort()` or `assert(false)`, you won't get a warning. The issue here is that the compiler doesn't know that raising a `NSException` will interrupt program flow. – Sulthan Sep 27 '13 at 12:03
1

@sulthan, thanks man, I need to dig into that more now. But I have faced this warning even without `NSException` scenario – geekay Sep 27 '13 at 12:32

score 1 · Answer 3 · answered May 01 '12 at 16:46

1

The warning is there simply because not every path through the code ends with a return statement which the compiler recognizes as potentially problematic. That said, you probably shouldn't be throwing an exception here and should instead be generating an NSError and returning nil. The differences between exceptions and errors in objective-c are explained here and here.

answered May 01 '12 at 16:46

Sean

5,810
2
33
41

right, it has nothing to do with `NSException` and this warning would've occurred even if there were any other (non-return) statement as a last statement. – geekay Sep 27 '13 at 11:47

NSException raise:format: as the last statement in a method

3 Answers3

Linked