Disable Exception Handling?

[Glenn9999]

I'm using an ActiveX object and by its instructions it has its own exception object. Now the problem I'm running into is that it seems Delphi is clearing the data out when it detects the exception so I can't use it.

A basic example:

try
  ICallResults := IWorkMethod.DoSomeWork;
except
  On E: EOleError do
    ...
end;

Now Delphi will go into the except section for any exception the statement makes, which is okay to a point. But ICallResults includes a IWorkException member which seems to have some better information reporting, according to documentation, that I can get out of the EOleError object (best I can do is "The Hex error is 0x1234567").

While I could be misunderstanding the documentation about what exact information IWorkException returns, it seems Delphi isn't giving me a shot to try and access this object (ICallResults doesn't seem to return correct data) in order to see whether it will produce something more meaningful.

Any ideas?

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[MagicFrisbee]

So it's not as simple as accessing the IWorkException object from the ICallResults object? There would have to be a property or function that returns an IWorkException pointer. Unless you're saying the resulting object can be "cast" as an IWorkException.

GIS Programmer
City of Orem, UT

http://gis.orem.org

 

[Glenn9999]

So it's not as simple as accessing the IWorkException object from the ICallResults object? There would have to be a property or function that returns an IWorkException pointer. Unless you're saying the resulting object can be "cast" as an IWorkException.

Seems not. When I have a EOleError exception, I try accessing that (ICallResults.IExceptionCollection.Count to be much more specific) and it's always 0, and the debugger doesn't show it to be valid if I try to look at it that way.

Like was said, I could be misunderstanding things, but I wouldn't think the exception object would be there if it didn't return errors every once in a while.

In the meantime, I have my app simply returning the exception values on a modal dialog box, which hopefully will work.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[MagicFrisbee]

I've done a lot of COM programming in my time, and it's not common to see the name of a property start with an unnecessary letter "I", like you showed in ICallResults.IExceptionCollection. In my experience, the property would be called ExceptionCollection (or Exceptions) and would be of *type* IExceptionCollection. However, your code DOES compile, so I wonder what's going on there. Do you want to copy and paste the definitions of those interfaces in this forum (hiding any proprietary or unnecessary things like GUIDs) so I can better understand the object model and how to grab those errors?

GIS Programmer
City of Orem, UT

http://gis.orem.org

 

[Glenn9999]

I was trying to generically show what was going on and not unnecessarily make the question more complex than it needed to be.

ICallResults.IExceptionCollection.Count is as follows:

1) Something like CallResults: ICallResults as defined.
2) ICallResults has a property of type IExceptionCollection (let's call it a definition like: ExceptionCollection: IExceptionCollection. This one is nothing different than any "Collection" object, it has a count property and a set of items to enumerate.

Like was said, I was trying to return something more logical than only a hex error code without going to a lot of work trying to translate all the possible error codes, but if I have to live with just a hex code that is fine. It may be that this doesn't work like I thought it would (wouldn't be the first time).

More my problem though at the moment is:
1) that I'm trying to get the exception code to stop whatever function it is called within, but it falls through with everything I've tried (usually in effect ignoring the error to begin with). So usually I end up having two or three if statements depending on whether the except section is encountered.
2) If you look at the error codes, not all of them are catastrophic errors. Is there a generic way to distinguish those and make it be silent on the ones that are not catastrophic? I noticed that the high order bit is set in the error code for all the catastrophic errors, so is that the generic rule for anything COM/ActiveX?

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[MagicFrisbee]

You raise some good questions and some good observations. I understand how important it is to keep the question short without going into all the gory details, so thank you. I have not noticed a pattern between catastrophic and non-catastrophic error codes. This could be a vendor-specific thing. It could be that the COM objects are handling their own exceptions in their own way. From what you're describing, you may be at the mercy of the component vendor, which is too bad. Their documentation needs to be better. It sounds like once the exception is thrown, you catch it, then some clean-up code is being called that you don't want to get called. I don't know how to get around that. If these are components you bought, hopefully you have support and/or maintenance with the product to file a bug report or a support request. My guess is that this is not possible, given that you are posting the question here. I'm sorry I couldn't help you further, Glen9999. You've helped me in the past and this is no way to repay you.

Do any other of you Delphi experts know how to answer glen9999's question? If so, please reply. His concern is still not resolved! :\


GIS Programmer
City of Orem, UT

http://gis.orem.org

 

[whosrdaddy]

MagicFrisbee,

I think you already said enough: The problem lies within the COM object, nothing one can do about it (in delphi or any other language)

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!