views:

160

answers:

2

I have a Cocoa app which interacts with a server and displays a GUI. If there is a fatal error, I display an alert and exit. I'd like to set the exit status to a non-zero value to reflect that an error occurred, for ease of interaction with some other UNIX based tools.

Unfortunately I've been unable to find a good way to do so - NSApplication doesn't seem to have any way to set an exit status. At the moment, I've subclassed NSApplication and added an exitStatus ivar (which I set in my app delegate when necessary), then overridden -terminate: so that it calls exit(exitStatus). This works fine, but it seems a bit grungy to me, not to mention that I may be missing something important that the standard terminate: is doing behind the scenes. I can't call [super terminate:sender] in my subclassed method, because that exit()s without giving me a chance to set the status.

Am I missing something obvious?

+3  A: 

In short, you either call exit(3) and completely bypass the standard Cocoa tear down mechanisms or you don't get to set the exit code (without jumping through the hoops as you describe.

As Jason mentioned, there isn't anything critical to the system that happens during app tear-down. Your app, on the other hand, may have something critical, but that is entirely because of your app's implementation (and not anything in Cocoa, by default).

But, really, don't do that -- user's love to force quit out of spite and your app should be engineered to not fail catastrophically as a result of that.

bbum
A: 

There are other cleaner methods for interacting with unix based tools. For example, you could simulate the exit code by writing some code in a text file, from where the tools could pick it up, without hacking your app to return a code. It could also be possible to use the app's stdout/console.

Jaanus