I wonder if is possible display a dialgo when a unexpected error happend in the iPhone (and not quit blindy the app!) and have time to log or send by email the crash...
Yes. For starts implement NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler) and then use something like Crash Reporter. Good stuff.
I don't know if you can show a dialog, but you can probably do some logging by specifying a top-level exception handler using the function NSSetUncaughtExceptionHandler
I remember there being a method you could override in your application delegate class that would be called in the event of an unhandled exception. A few days ago someone wrote a blog post where they shipped off the exception information to a web service from that method.
I apologize that I can neither find the name of the method in the UIApplicationDelegate protocol or the blog post I saw the other day. Apple's online documentation seems to be un-searchable at the moment (grrr!) and I cannot remember where I saw that blog post - if I find it, I'll edit this post to include a link to it.
But it may be possible to have some sort of recovery, or at least the ability to store off error information to disk so it can be sent later.
Related
I have got a proj work, which works in this way...
An app which connects two guys, I'm able to send a message and the other one receives it in his message inbox. Can't there be done something such that, the sent message can be read inside my application?
I have found out some ways, like using push notifications, using sqlite. Kindly suggest me which one works out well.
Thanks in advance.
I will choose push notification to implement. But in this implementation lot of server side code has to be implemented. So my suggestion is to go through the docs and check that all your requirements are fulfilled.
For more info: http://www.raywenderlich.com/3443/apple-push-notification-services-tutorial-part-12 and http://mobiforge.com/developing/story/programming-apple-push-notification-services
The above URLs have the implementation code and profiling. The below one will give you a proper understanding of push notification.
https://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html.
Is there a way to include an error description string in a crash report? I'm talking about crash reports that are sent via iTunes Connect. It would be nice if I could log the reason for a crash.
This question asks about including console output, but I'd be happy just to able to include an error description string, without resorting to a 3rd party library.
EDIT:
There are errors I can detect where it's unwise or impossible to attempt to recover, because the program is probably in a corrupt state. I'd rather not catch these exceptions so that I get automatic error reporting with a stack trace. Sometimes, there is extra information that I'd like to log (that cannot be deduced from the stack trace), such as the current state of a state machine.
How about a third party crash reporter? I've integrated QuincyKit, and even found a way to annotate them.
Also, when the app actively begs for the crash report to be sent to the support, you get much more of them. The things you learn...
I've searched and searched. There seems to no way to annotate a pending crash report. If someone comes up with an answer, I'll change the accepted answer.
I trying to write a a crash report feature that when you launch the app after a crash, it will offer to send the crash report to the server. I can't find how to get the crash log within the app. I saw there is a framework that doing so (PLCrashReporter), however this framework is large and I don't need most of it's features.
Does anyone knows how to simply access the log?
Thanks,
Guy.
I guess I don't have the karma to add a comment to Nimrod Gat's answer, so I have to provide my follow-up here. I'll try to make it worthy of a standalone answer.
It's very, very difficult to write a safe, correct, and reliable crash reporter, especially one that runs directly in-process. The code referenced in Nimrod Gat's answer is not correct and honestly, that blog post should be retracted. Signal handlers must only run async-safe code, and that code isn't async-safe:
http://www.cocoadev.com/index.pl?SignalSafety
Crash handling is even more complicated than normal signal handling, because that you can't expect the process to continue to run successfully after your signal handler returns.
It's tempting to think you can just hack together a simpler solution, and it will work some of the time, but there's a good reason people like Google's engineers have thousands of LoC dedicated to reliable crash reporting:
http://code.google.com/p/google-breakpad/
On iOS, you should just use PLCrashReporter. On other platforms (such as Mac OS X) you should use Google Breakpad. There's no point in re-inventing this wheel unless you're going to do it not only correctly, but better than what already exists.
I had this similar issue and the PLCrashReported seemed too complicated for what I wanted to do.
Note that you can't access the crash report generated by Apple, the PLCrashReport generates it's own reports and store them in the user's cache folder.
Eventually, I used the following example:
http://cocoawithlove.com/2010/05/handling-unhandled-exceptions-and.html
it's very simple and easy to use, just register exception and signal handlers using:
NSSetUncaughtExceptionHandler(&HandleException);
signal(SIGABRT, SignalHandler);
signal(SIGILL, SignalHandler);
signal(SIGSEGV, SignalHandler);
signal(SIGFPE, SignalHandler);
signal(SIGBUS, SignalHandler);
signal(SIGPIPE, SignalHandler);
and get the stack trace using the backtrace method in UncaughtExceptionHandler class.
Maybe a better solution will be to use a fully specialized end-2-end solution/service? Such as http://apphance.com. It is currently in closed beta testing phase, but you can ask for participation and we'll get back to you pretty quickly. The only thing you need to do is to register for an API key and embed a small framework library into your app (or .jar file in android). Then you have remote access not only to crashlogs but also to a debug logs generated by the application - which makes it much more useful. It is for now targeted to be used during testing, but there will soon be a lite version that you will be able to embed into app-store-released application.
Inside the framework we are doing all the magic of plugging-into the apple's framework and getting the crashlog information, decoding stack traces, even handling out-of-memory cases. All the comments by #nupark hold very much true: We spend countless hours on making it works seamlessly - thread-safeness, making sure that we can do the job of saving everything within the time required by Apple's framework before your app get finally killed, getting stack trace from out-of-memory case (that one was really difficult). The same for android - we've done some clever tricks there to make sure it's really working fine.
Disclaimer: I am CTO of Polidea, company which is behind apphance and co-creator of the solution.
There are a bunch of (SAAS) E2E solutions that you may be very happy to know.
Very very simple to integrate into your application
Have Fun...
crashlytics (Free and my preferred)
hockeyapp
bugSense
Crittercism
In our days you may use the built-in crash reports (iOS & Android)
iOS (Itunes connect) - Viewing Crash Reports
Understanding Crash Reports
on iPhone OS
Reading Android Market Crash Reports
Is there anyway to implement a global exception handler for iPhone apps such that exceptions, instead of silently crashing the app, could allow for some sort of message?
I can understand if it's not do-able since the program may be in an inconsistent state, but it'd be nice to at least tell users "Sorry - something went wrong!"
Thanks!
Check this question for the answer. It seems to indicate that you'll be getting junky stack traces, but you definitely can set a global exception handler. Good luck!
I'm trying to make a general error handler for an iPhone app that brings the user to a recovery screen whenever any general error is thrown in the application without putting a try/catch block around every single method in the application.
Using NSSetUncaughtExceptionHandler doesn't work because the application terminates after the handler is run.
Is there any way to change this behavior, or use any other handler that will catch exceptions in general and not cause the application to exit afterward?
And please, no non-answers about whether it's a good or bad idea.
The original poster has probably solved his problem by now. However, for anyone who comes across this in the future...
Matt Gallagher wrote an excellent post on catching unhandled exceptions and signals a few months after this question was posted. I find it to be much more informative than the answer referenced above by Scott.
In particular, Matt's post describes how to attempt a recovery (if appropriate) that allows your app to keep running, and even displays a UIAlertView with error information if you want (hint: it involves creating a new run loop).
This was answered here. You can read more about the responder chain and catching the exceptions here. The write up from 1 is really good and explains how to deal with what you are doing.