Ticket #210 (closed enhancement: fixed)

Opened 5 years ago

Last modified 5 years ago

Default exception handler

Reported by: jppavao Owned by:
Priority: critical Milestone: 1.0
Component: Debugging Aids Version: version 0.8
Keywords: Cc:

Description

We should implement something similar to what Xcode does to log exceptions. We should catch all un-handled exceptions high in the call stack, logging their backtrace and then send it all to Sapo. Also warn the user that things have gone awry and suggest relaunching the app.

Change History

Changed 5 years ago by jppavao

(In [240]) When an exception goes all the way up the call stack and ends up unhandled, we now tell the user about the situation and collect all the info we can, including the call stack where the exception was thrown. The alert dialog that is presented to the user explains what is about to happen, and allows the user to choose whether to send this info to Sapo before the app is relaunched automatically or not. References #210.

Changed 5 years ago by jppavao

(In [244]) Improved the exception reporter alert window. Having sheets open prevents the app from terminating, so we now close all sheets before relaunching the app. Also, if we catch one or more unhandled exceptions while this modal alert is being displayed, then we collect their stack traces and send them all in one go, without displaying more alerts. Closes #212, references #210.

Changed 5 years ago by jppavao

(In [245]) Moved all the unhandled exceptions and crash logs reporting code to a new LPCrashReporter class. When an unhandled exception is thrown, we now tell the user about it only once. If the user agrees to send the report, it is now uploaded by HTTP POST to a local web server. On the crash reports front, we can now list every crash report that hasn't been uploaded yet, but we don't do anything about it at this point. References #210 and #211.

Changed 5 years ago by jppavao

(In [246]) Fixed the references to the LPCrashReporter.{h,m} files in the Xcode project. References #210 and #211.

Changed 5 years ago by jppavao

(In [248]) Improved reliability of application termination after an unexpected condition is caught. References #210 and #211.

Changed 5 years ago by jppavao

  • status changed from new to closed
  • resolution set to fixed

(In [249]) Finished the implementation of the reporter of unhandled exceptions and previous crash logs. Closes #210 and #211.

Changed 5 years ago by jppavao

(In [258]) Improved the crash reporter to also report Objective-C runtime exceptions that get caught and handled deeper in the call stack. The stack backtrace is now annotated with a lot more info, including the nearest symbol names and the list of loaded dyld binary images involved in the call stack, complete with their base load addresses and slide amount. This will be needed to correctly resolve the symbols afterwards on a development machine using a dSYM bundle to get even more debug info. References #210.

Changed 5 years ago by jppavao

(In [283]) Added the Operating System build nr and version nr to the unhandled exception reports. References #210.

Changed 5 years ago by jppavao

(In [286]) Some of the higher level initialization code was being run while the app was still being launched. Moved that code to a slightly later stage in the application startup process in order to allow the NSApplication exception handler to be setup appropriately before our code gets run. It also makes the app icon bounce even less in the Dock.

We were trying to report any exceptions that were raised and then ignored by the AppKit?, which prevented them from reaching our top-level exception handler. However, this proved to be bad, as we were also catching some harmless exceptions that were expected in the normal flow of the application but which caused us to terminate the app. We no longer try to report back this kind of exceptions. If Apple thinks ignoring exceptions is good and doesn't let us customize that behavior, then let it be.

References #210.

Note: See TracTickets for help on using tickets.