Windows exceptions not handled when locking working tree

[Simon Kersey]

In attempting to fix a bug reported on BzrExplorer (Bug 568728) I came across an issue with exception handling across different platforms.

The bug exhibited itself when a working tree displayed in Explorer was renamed or deleted using the OS and the repository tab in Explorer was refreshed.

On Windows an unhandled exception was displayed for a pywintypes.error with a stack dump for "File "bzrlib\lock.pyo", line 352, in _open error: (3, 'CreateFileW', 'The system cannot find the path specified.')" caused by qbzr attempting to obtain a lock on a working tree that no longer exists.

Review comments on a qbzr patch to fix the problem indicated that on UBUNTU a 'friendly' dialog is displayed rather than an unhandled exception. This is managed by qbzr and relies on the return from bzrlib.trace.report_exception() being less than bzrlib.errors.EXIT_INTERNAL_ERROR to detect that a more friendly message should be shown.

The bug in bzr is that it does not handle the Windows specific errors in away that allows them to be treated generically downstream.

[Martin Pool (mbp)]

Perhaps pywintypes.error should be treated the same as OSError in report_exception?

[Alexander Belchenko (bialix)]

In this particular case pywintypes.error comes from pywin32 package and it's indeed equivalent of OSError (WindowsError).

[Martin Packman (gz)]

Ah, okay, so an OSError is considered the user's fault, and reported differently to other kinds of exception? If the right fix is just treating this error as not-internal, I can do that.

In a sense this is an upstream bug as pywin32 should throw WindowsError from win32 functions like ctypes, or at least their exception type should be derived from WindowsError rather than plain Exception.

[Martin Packman (gz)]

Workaround landed in r5246, will try and do prettier formatting later as well.