I'm just proposing this as a more informative way to catch what would be sigaborts before they abort and force your app to stop.
If you wrap the call for non release code you can debug it faster rather than spending the time to find out just what sig aborted.
Just seems to make more sense to me to get to finish line faster since you know exactly what is getting passed the invalid message.
Sent from my Verizon Wireless BlackBerry
From: Jens Alfke <email@hidden>
Date: Wed, 19 Sep 2012 14:42:17 -0700 To: Alex Zavatone<email@hidden> Cc: Glenn L. Austin<email@hidden>; email@hidden Users<email@hidden> Subject: Re: Weird crash on iOS
On Sep 19, 2012, at 11:04 AM, Alex Zavatone < email@hidden> wrote: Would it make sense to wrap performSelector with "if object responds to Selector" then issue it, or return the proper error?Much more informative than another SIGABRT in my book. A little defensive programming.
I disagree. If you try to send a message to an object that it doesn’t understand, that’s a programmer error, i.e. a bug. It’s not something that should ever be expected at runtime, in most apps. That’s the kind of thing exceptions are for.
If you tried to catch every error condition, the result would be madness. You’d have to put in your own range checking before every -objectAtIndex: call and check for a nil parameter on every -objectForKey, etc. for instance.
The exception is actually pretty informative (modulo Xcode not reporting it very well unless you set a breakpoint.) By contrast, if this results in an error code that then trickles up six levels of calls to your main loop which reports an error, you then have pretty much no idea of where the error came from, because the error doesn’t carry its call stack with it the way an exception does.
—Jens
|