locked
Exceptions not caught by Application.UnhandledException event. RRS feed

  • Question

  • Hi,

    The Application.UnhandledException event essentially only fires for exceptions happening on the UI thread.

    I want to catch all exceptions in my app for crash-reporting purposes. What else can I hook to achieve this?

    s


    Blog: http://socialebola.wordpress.com

    Wednesday, October 17, 2012 7:36 AM

Answers

  • Hi Shahar,

    Thanks for clarifying your scenario. You certainly have valid points for consideration, however the current framework structure does not allow you to do that. The only solution available is to identify the potential regions of code that could throw and decorate that code with a try/catch. For code that is not under your control, it is probably an issue with the vendor of the control and even the vendor should use the try/catch approach rather than having the exception go unhandled and crash your process.

    Thanks,

    Prashant.

    Monday, October 29, 2012 8:46 PM
    Moderator

All replies

  • So you are saying it's impossible, saramgsilva? :(

    Blog: http://socialebola.wordpress.com

    Friday, October 19, 2012 9:27 AM
  • I conclude there are problems and they are working in this.

    Sara Silva

    Friday, October 19, 2012 9:38 AM
  • Can you give a code example of what you are trying to achieve here? I understand that you want to catch all exceptions, so why are you not placing try/catch blocks in each of your user code functions that could throw an exception and then perform the crash-reporting from the catch block of your application?

    Friday, October 26, 2012 11:08 PM
    Moderator
  • Hi prashant,

    No real code example, but there are a number of scenarios/reasons why this does not address my requirements:

    1. Not my code: I use libraries I don't control and as such, cannot place breakpoints in them. One good example is the ad control. On windows phone, the equivalent control accounts for 30% of my crashes on most apps. Some crashes I have been able to fix by changing my apps behavior, however, they occurred not due to direct calls made by my app, but rather, in background tasks it due to events. In these instances, I don't have any place I cab catch on.

    2. Code cleanliness: An average app of mine potentially has dozens of entry points that can do stuff that is not supposed to throw. However, I am not a perfect developer and every now and again, I make mistakes and they do throw. This happens rarely enough that just adding try/catch wholesale seems unnecessary. That's exactly what a real unhandled exception handler is for - stuff you don't expect.

    3. Async platform code: some parts of the platform are async in ways that are not totally accounted for. Again, drawing from WP experience.. Various navigate methods and tasks are called as regular methods but are actually async. If you accidentally call them twice, the app crashes. Sometimes, the crash happens on the async thread running the operation. As such, I will never know about it.

    there are probably other reasons I forgot, but this should give you an idea.  


    Blog: http://socialebola.wordpress.com

    Friday, October 26, 2012 11:51 PM
  • Hi Shahar,

    Thanks for clarifying your scenario. You certainly have valid points for consideration, however the current framework structure does not allow you to do that. The only solution available is to identify the potential regions of code that could throw and decorate that code with a try/catch. For code that is not under your control, it is probably an issue with the vendor of the control and even the vendor should use the try/catch approach rather than having the exception go unhandled and crash your process.

    Thanks,

    Prashant.

    Monday, October 29, 2012 8:46 PM
    Moderator