There is no way to disable grouping of similar errors.
It would be helpful to us to know what errors you believe are
completely different, and which should've been grouped and didn't.
Errors are currently considered unique if all of the following are
equal: the error class, the last file and line number in the
backtrace, the controller and action, and the server environment
Ah... so that might be the source of the issue then. How are you
determining "last file and line number" in the backtrace?
In iOS apps, the backtrace that is being saved is actually in
reverse order, so the top-most function call on the call stack is
actually the first line of the backtrace. And actually, given that
all iOS apps are spun-up from the same one-line of code in main(),
the bottom-most function call on the call stack (and the very last
line of the backtrace) is always the same.
Could this be one of the reasons we are seeing inconsistent
Actually... another note: sometimes, the top-most call in the
stack trace is actually a framework-level call (e.g. something
within the iOS SDK itself)... but the "bug" is actually from our
user code making the call to the iOS SDK.
While both the bottom- and top-most call in both backtraces are
actually more or less the same, you can see from the rest of the
backtrace that these two errors are actually quite different.
What's even more interesting is that they actually have two
completely different error messages as well:
NSInvalidArgumentException: -[QSListFormItem addFormItem:]:
unrecognized selector sent to instance 0x6ac38d0 vs.
initWithString:]: nil argument
Hope that helps to shed some light on some of the issues we are
Thanks for the tip -- I've upgraded and it looks like it is
doing a MUCH better job of the grouping. Thanks so
However... just a note (and this was an issue with the older
version I was using as well) -- the controller is always blank. The
action is now being propagated correctly, but the controller has
been and continues to be "", even though I'm using the latest
version of the notifier that I pulled from github.
Let me know whenever you get a chance. Thanks for your help!
You have to do a little bit of work to get the controller field
to populate properly. If you use the
setRootViewController: method of UIWindow
when your application launches (available only in 4.0 or higher)
then that field is populated by walking the controller tree
automatically. If you only call addSubview: on your
application's window then you have to implement the
HTNotifierDelegate method called
rootViewControllerForNotice. Once you do one of those
your controller will populate for all exception notices (but not
signal ones due to the complicate nature of UNIX signals)