2

we currently have an application with 2 pdfviewers for document comparison. Unfortunately, there are some pdf files causing exceptions either at loading them into the viewer or when being rendered by the viewer. The exception comes from within a 3rd party control.

So we tried to solve some of those problems by binding to AppDomain.CurrentDomain.FirstChanceException. When such an exception is thrown, a message should be shown in the viewer having the problem.

For we can at time current not distinguish from firstchanceexception's arguments which viewer has a problem, the message is shown in both viewers, even in the one who could have displayed his document without issues.

So the question is:

Is there any way to find the source of the exception?

sender is targeting towards application.run, not very helpful.

FirstChanceExceptionEventArgs are targeting at a type used by our viewer-controls, but without any indication which one has triggered the exception.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
  • `AppDomain` is a place of last resort to handle exceptions. Tracing it back to a particular component from there isn't very realistic. Analyze the stack trace of the exception to see where it's thrown and add a handler *there* (or at any place higher up the chain that you control) where there's enough context to do something about it. This may involve hooking into some component's message loop if you're unlucky, and you may need to run your application under a debugger first just to get at the correct location. – Jeroen Mostert Nov 30 '16 at 16:43
  • The exception comes from within a 3rd party control. Is there a way to hook into anything there? After the stream has been loaded and DocumentLoaded event has been thrown, we have no control whatsoever. – Michael Würthner Nov 30 '16 at 16:47
  • 1
    My first advice would be to get a better control, because throwing exceptions in a GUI control for anything that's not a programmer error is just not done. A proper error signaling mechanism would go through an event handler. My second idea would be to load the documents in sequence, not in parallel, so you know which viewer is active if an exception occurs. I have no immediate clever ideas for distinguishing the component otherwise; the problem is that there is no natural association between the component and the thread the exception happened to be thrown on. – Jeroen Mostert Nov 30 '16 at 17:14
  • I feared for that already but had to try. Thank you very much for your practicable advice. – Michael Würthner Dec 01 '16 at 07:59

0 Answers0