"Ian Bartholomew" <
[hidden email]> wrote in message
news:905jcm$1dhs$
[hidden email]...
> I came across the following whilst trying to use the WebBrowser wrapper.
It
> may be expected and it is my limited understanding of what should be
> happening and/or what I should be doing that is wrong - but it's a bit
> confusing. Demo.... edit the method
>
> WebBrowserShell>>OnDocumentComplete: anIDispatch URL: urlOrPIDL
> self halt
>
> and start up the WebBrowserShell application. It, as expected, halts
almost
> straight away. Now edit the method to read
>
> WebBrowserShell>>OnDocumentComplete: anIDispatch URL: urlOrPIDL
> #(1 2 3) detect: [:e | e > 10].
> self halt
>
> Now, not only does the #detect not bring up the expected error but the
#halt
> also fails to work.
Like much strange behaviour, the simplest explanation is actually the
correct one :-). If you look at the implementation of
AXDispatchImpAbstract>>Invoke:rid:lcid:&c you will immediately see why. All
errors are trapped and converted to an HRESULT code to be returned to the
caller.
You may wonder why this is done, and I was in two minds about it myself. The
point is that one is acting as a COM server in implementing the dispatched
methods or events, and the correct behaviour in a runtime situation would be
to return an error code to the caller, not raise an exception, because COM
doesn't allow one to pass exceptions across interfaces.
So, converting the exceptions to HRESULT codes is the correct behaviour for
a runtime app., but it does make debugging harder I will agree. I think what
is needed is a capability like one sees in VC++, where one can specify the
whether to break when certain exceptions occur, or only if they are not
handled. Maybe just a simple routing via the SessionManager so that the
development session manager could behave differently (although even then one
needs to be able to turn off the trap in order to test the actual runtime
behaviour of the application). As you can see I'm still thinking about how
to enhance the tools for better debuggability of COM servers.
In the meantime either keep an eye out for "Error dispatching " methods on
the Transcript (and yes, I'm also thinking about how to make the Transcript
flash in the way that MSN Messenger does when it needs attention), or add a
temporary override of #errorDispatching:&c to AXEventSink which perhaps has
a breakpoint in it.
Regards
Blair
Locked
