CScriptEngine::CreateScriptEngine() - catching HRESULT?

Posted by Twisol on Thu 09 Sep 2010 09:31 PM — 3 posts, 10,780 views.

USA #0
While working on CScriptEngine I saw that CreateScriptEngine() has a somewhat odd catch clause:

catch (HRESULT hr)
  {
  ShowError (hr, "starting scripting support");
  DisableScripting ();
  return true;
  }


I can't really tell where this HRESULT is thrown. All of the obvious points are already covered by the use of ShowError at those locations. Unless one of these ShowError()s is never called because an HRESULT is thrown inside the call, I can't figure out what's going on here. Any chance someone could shed some light on the matter?
Amended on Thu 09 Sep 2010 09:33 PM by Twisol
Australia Forum Administrator #1
That code is old. So there are two possibilities. One is it is just wrong. The other is:

Basically the only thing that can throw something is in the try { ... } block.

So, one of the calls to QueryInterface, GetIDispatch, AddNamedItem, SetScriptState, SetScriptState, GetScriptDispatch could potentially do it.

Now, they seem to return an HRESULT (rather than throw one) and that returned result is tested.

However I suppose it is possible that a particular script DLL (remembering that we eventually end up inside Jscript.dll, or Perlscript.dll or something like that) might throw an exception.

So I suppose that line is to catch it.

A quick Google is inconclusive. There is some talk of script engines throwing exceptions. Whether that applies here or not I don't know.

This was all added in version 2.00 of MUSHclient in May 1997 - 13 years ago. I may have found the exception catch was required at the time, or I may have blindly followed example code when I was working out how to add scripting.
USA #2
Hmm, I see.

I found a page [1] that explained how to "catch" HRESULTs, since handling them linearly can lead to ugly code. It mentions that COM is C-based and doesn't use exceptions (in contrast to MFC I might add), so I doubt that the script engines are allowed to throw exceptions.

Quote:
The reason why we can't do this is that Microsoft decided to use a C style mechanism for error handling in their COM code. We can't entirely blame them though as they wanted programmers to be able to write COM objects in C as well as in C++. This means that we cannot make direct use of C++'s very elegant exception mechanism that is designed to handle exactly these sorts of situations. COM's C lagacy stops exceptions from being used properly to handle this otherwise we could just leave the code as it is above.


[1] http://www.kirit.com/Handling%20COM%20errors%20in%20C%2B%2B