Hello Rob, I implemented the error event handler, and put some try-except blocks around calls to the COM object. The event handlers are triggered when the errors happen but that error boxes still show. The try-except blocks are not catching any exceptions (exceptions are not happening there.)
There are a few different errors, one of the mostly seen ones says "APPLICATION: operation failed" in the middle of the error dialog box. It's related to Skype4COM functionality. Not a generic error. I'm having a hard time locating the error. I'm not sure about the COM threading models. How should I change it? I'll try application's OnException handler to see if it catches anything. Thanks, Jack Monday, November 12, 2007, 10:54:55 AM, you wrote: > JLIST wrote: >>>> I'm using the Skyp4COM object in a delphi app. Sometimes the >>>> application (not the COM object itself) shows error message dialog >>>> boxes from the COM object. There is an error event from the COM >>>> object and I'm catching that, but this doesn't help. >> >>> Are you sure you're catching the right exception type? >> >> As a matter of fact, I'm not catching any exceptions. I'm only >> handling the error event. > OK, time to be more precise. When you say you're handling an event, that > suggests you have a component on your form and you've assign an > event-handler method to an event property in the Object Inspector. > When you say you're catching something, that means there's an exception. > Are you catching an exception, handling an event, or checking the return > value of a function? >> When the exceptions happen, the error >> events are also fired but handling them doesn't prevent the error >> messages. > What causes the events to fire? That is, where in the code does an > exception get make an event handler get called? >> I think it's a good idea to put some try-catch blocks >> around calls to the COM object. > Not unless you actually know what kind of exception you plan on catching, > and you know what you're going to do with it once you catch it. Otherwise, > you're only hurting things. >> However, I suppose this does not >> help if the COM object is doing something in its own threads and >> an exception happens in those threads? Is there a good way to >> catch those exceptions? > Not really. An unhandled exception causes the thread to die. MadExcept can > catch the exception and tell you about it, but the thread still has to die > because there's not really anything anyone can do about it at that point. >>> While the message box is showing, press the "pause" button in the IDE. >>> Then bring up the call stack, and you'll see exactly who's displaying >>> the >>> dialog box. >> >> The thing is, during debugging, the error is difficult to reproduce. >> It only happens when traffic is high, with many concurrent users. > Is it always the same kind of error? What error is it? > Are you sure you have the threading model right for your COM objects? > (Apartment, free, etc.) >>> A likely candidate is Delphi's built-in exception handler. It gets >>> invoked >>> whenever an exception goes unhandled while a control's event handler is >>> active. >> >> Is there a generic way to replace the exception handler and catch >> those uncaught exceptions? I suppose there must be, because that's >> how tools like madExcept work? > An easy way is to handle the application's OnException event. A better way > is to buy MadExcept and use it. >> I'll start with putting in some try catch blocks first. Thanks! > Don't catch exceptions unless you know what you're going to do with them. > Logging them is not the same as handling them. Handling an exception means > you've done something to mitigate the problem that caused the exception in > the first place. _______________________________________________ Delphi mailing list -> [email protected] http://lists.elists.org/cgi-bin/mailman/listinfo/delphi
