Re: Variant arguments & com function calls

That makes some sense, but why not rename COMError to Win32Error, JniError
or StructuredExeceptionError since you don't have to be doing anything COM
to raise this type of error. You only need to be doing JNI calls to have the
potential to cause an ACCESS_VIOLATION.

Robert

-----Original Message-----
From: Discussion of Java/Win32/COM integration with Jawin
[mailto:JAWIN@xxxxxxxxxxxxxxxxxxx] On Behalf Of Morten Andersen
Sent: Tuesday, August 03, 2004 12:52 AM
To: JAWIN@xxxxxxxxxxxxxxxxxxx
Subject: Re: [JAWIN] Variant arguments & com function calls

Hi Robert

Robert Hastings wrote:
> We should probably add this to COMException or COMError (Why do we have
> both?)

COMException is a standard Exception, whereas COMError is a runtime
error. So I assume the intention with these two, is the standard one for
Exception vs. Error: The Errors should normally not be caught by an
application, or at least one should have a really good reason to do it.

So eg. the new catch-all native errors in the DLL, I implemented
yesterday (see the HANDLE_WIN32_EXCEPTIONS-macro in JNIException.h)
throws COMErrors. Because if you have code that make Jawin trigger eg. a
native ACCESS_VIOLATION, you should only catch and continue if you know
what you're doing since the native code could have severely destabilized
the JVM. But at least throwing a Java COMError gives the programmer the
opportunity to catch it if he wants to.

But we could also change to a "RMI" style, where all failures are (as
far as I know) subclasses of the RemoteException. Which means the
programmer is forced to handle everything?

>
> public static final int DISP_E_PARAMNOTFOUND = 0x80020004;
>

If this works it should probably be added in the COMException.

Best Regards
Morten