win32com/server/policy.py tries to call as string

[dlech]

Note that issues in this repository are only for bugs or feature requests in the pywin32.

If you need support or help using this package, please follow these instructions - support or help requests will be closed without comment.

For all bugs, please provide the following information.

• Expected behavior and actual behavior.

https://github.com/mhammond/pywin32/blob/main/com/win32com/server/policy.py tries to call error which is a string.

error is defined at

pywin32/com/win32com/server/policy.py

Line 103 in e1c0237

error = __name__ + " error"

and there are 4 instances where it is called

• pywin32/com/win32com/server/policy.py

  Line 211 in e1c0237

  raise error(

• pywin32/com/win32com/server/policy.py

  Line 363 in e1c0237

  raise error("This class does not provide _invokeex_ semantics")

• pywin32/com/win32com/server/policy.py

  Line 517 in e1c0237

  raise error(

• pywin32/com/win32com/server/policy.py

  Line 740 in e1c0237

  raise error("Object does not support Dynamic COM Policy")

• Steps to reproduce the problem.

Try to use a COM interface that does not exist.

program output:

pythoncom error: ERROR: server.policy could not create an instance.

Traceback (most recent call last):
  File "C:\Users\david\AppData\Local\pypoetry\Cache\virtualenvs\winsdk1-vNE5bx4W-py3.10\lib\site-packages\win32com\server\policy.py", line 151, in CreateInstance
    return retObj._CreateInstance_(clsid, reqIID)
  File "C:\Users\david\AppData\Local\pypoetry\Cache\virtualenvs\winsdk1-vNE5bx4W-py3.10\lib\site-packages\win32com\server\policy.py", line 211, in _CreateInstance_
    raise error(
TypeError: 'str' object is not callable
pythoncom error: CPyFactory::CreateInstance failed to create instance. (80004005)

• Version of Python and pywin32

[Avasam]

These kinds of issues are easily caught by type-checkers. I also noticed a couple more error; str in typeshed recently. I expect this to be resolved pretty soon as I turn on type-checking for more and more parts of the code.

[Avasam]

@mhammond It seems that during the transition to Python3, a lot of string error variables were left as strings, causing them to be called and raise TypeError: 'str' object is not callable. What should be done with those?

1. Make them their own error class, possibly inheriting from TypeError for historical reasons to prevent breaking any code that expects the incorrect TypeError to be re-raised?
2. Just use Exception directly instead (raising bare Exceptions isn't great, and pywin32 only have those in tests)
3. Re-use an existing exception (pywintypes.error?)
4. Other?

Fixing this will be necessary to enable the reportCallIssue check in pyright.

[Avasam]

@mhammond I can fix this, but I'm not sure what your preferred approach would be.

[mhammond]

These are not exceptions we expect to actually hit or have people catch, so I'd be fine with one of RuntimeError, TypeError or ValueError depending on the scenario - most of the above are probably TypeError I guess? Although ValueError would still be a candidate even though we are dealing with types (ie, in most cases the user isn't specifying the wrong type necessarily, but rather the type doesn't have what we expect.)

I'm open to ideas though - WDYT?

[Avasam]

I think that's gonna have to be a case-by-case.

First thing I noticed is that tests could simply use assert/AssertionError, that'll already safely take care of a handful of these and reduce the scope.

I noticed a few more that can sensibly be COMException instead.

Others are actually unused.

Most valid error = ... are just aliases for pywintypes.error, so I could transform error = "SomeModule error into error = pywintypes.error.

[mhammond]

Of the 4 listed above, I don't see how any of them could reasonably be a pythoncom.error - what would the HRESULT be?

I noticed a few more

Sorry, I only looked at those 4 quoted above.

[Avasam]

I meant pywintypes.error 🤦 Anyway, PRs incoming, starting with the tests.