StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>You can't, this appears to be by design. Details further below, but in short you have three options:</p> <ul> <li>Return no message and a VB friendly COM error, i.e. one <strong>well known</strong> by the VB runtime according to this <a href="http://support.microsoft.com/kb/827994" rel="nofollow noreferrer">KB article</a>; the VB runtime will translate this 'COM error' to a VB error plus message.</li> <li>Return an error message and DISP_E_EXCEPTION; the VB runtime will pass through this 'Server error' and your custom error message. This is what's implicitly happening on your second example, see below for details.</li> <li>Return no message and any other COM error, i.e. one <strong>not known</strong> by the VB runtime; the VB runtime will resort to the raw HRESULT plus the generic message "<code>Method '~' of object '~' failed</code>". <ul> <li>Please note that this runtime behavior does also apply, if you do supply an error message here, i.e. your message will simply be ignored! This is what's happening on your first example, see below for details.</li> </ul></li> </ul> <p>For the task at hand it boils down to two choices:</p> <ul> <li>If you want to supply contextually correct 'COM errors' for automation clients like VB (and likely you should) you must omit custom error messages.</li> <li>If you want to supply custom error messages for 'Server errors' (i.e. a custom error conditions regarding the functionality <strong>within</strong> your automation server) your only option is DISP_E_EXCEPTION.</li> </ul> <hr> <h3>Details</h3> <p>The VB runtime seems to offer only very restricted handling in regard to COM errors. This is likely for historic and/or technical reasons specific to the way VB has been implemented and not of particular interest here (keywords would be IDispatch only vs dual interface and ActiveX as a 'subset' of COM).</p> <p>While I've been unable to surface an explicit specification for the behavior outlined above one can figure it from digging through other sources:</p> <p>From the <a href="http://support.microsoft.com/kb/827994" rel="nofollow noreferrer">KB article</a> justadreamer <a href="https://stackoverflow.com/questions/1069585/how-can-i-return-both-an-error-string-and-error-code-to-vb6-from-an-atl-activex-c/1128085#1128085">pointed out already</a>: </p> <blockquote> <p>[...] a call is made to the GetErrorInfo method to retrieve the available error information. The runtime then determines whether bstrDescription has a value other than NULL. If the runtime finds a value other than NULL, [...], the raw HRESULT value is used in this scenario. If the runtime finds a NULL value, [...] Visual Basic then uses HRESULT to look up the corresponding Visual Basic error.</p> </blockquote> <p>This explains the behavior regarding your fist example: you did supply an error message, hence the runtime simply resorts to its generic message "<code>Method '~' of object '~' failed</code>" plus your <code>HRESULT</code>.</p> <p>The behavior of your second example is also consistent once you look at the definition of the (first listed) constructor for <a href="http://msdn.microsoft.com/en-us/library/57a9x7e4(VS.80).aspx" rel="nofollow noreferrer"><code>CComCoClass::Error</code></a>: it has defaults for the non specified parameters, especially 'hRes = 0'. The 'Remarks' section further states that "If hRes is zero, then the first four versions of Error return DISP_E_EXCEPTION.". Consequently this implicitly triggers the 'Server error' pass through behavior.</p> <p>Finally, for a concrete C++ implementation sample of a VB like automation client behavior see for example paragraphs 'Error handling' and the following 'Exercise 5' in <a href="http://msdn.microsoft.com/en-us/library/aa155776(office.10).aspx" rel="nofollow noreferrer">Automating Microsoft Office 97 and Microsoft Office 2000</a>.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload