Do not raise from close() on teardown paths

[Borega]

Process.close() and Thread.close() raise Win32Exception when CloseHandle fails — and both are called from __del__.

Raising from a destructor is unraisable: Python prints Exception ignored in: ... and carries on. Worse, during interpreter shutdown module globals have already been set to None, so raise Win32Exception() degenerates into:

TypeError: exceptions must derive from BaseException

That message says nothing about the actual failure, cannot be caught at the call site, and appears at a point where the program is already exiting. In practice consumers end up string-matching it to get a clean shutdown.

Fix

close() gains raise_on_error: bool = True:

process.close()                        # unchanged: raises on failure
process.close(raise_on_error=False)    # returns False instead

__del__ uses the non-raising form. Explicit calls keep their existing contract, so nothing changes for code that checks the return value or catches Win32Exception.

Two related cleanups:

• The handle reference is now dropped whether or not CloseHandle succeeds. Retrying a handle that will not close only repeats the failure, and holding the attribute keeps a dead object alive.
• Process.close() returns True when there is no handle rather than calling CloseHandle(0), making it idempotent (Thread.close() already did this).

Tests

Adds tests/test_teardown.py (7 tests), including a regression test that runs a subprocess which leaves a Process and an open Thread alive until interpreter shutdown, then asserts stderr contains neither must derive from BaseException nor Exception ignored.

Both close() variants are covered in raising and non-raising mode, and a destructor test installs sys.unraisablehook to prove __del__ stays silent when CloseHandle fails.

Full suite: 81 passed, 2 skipped.

[Copilot]

Pull request overview

This PR prevents noisy/unhelpful exceptions during object teardown by making Process.close() / Thread.close() optionally non-raising, and using that mode from __del__ to avoid unraisable exceptions during interpreter shutdown.

Changes:

• Add raise_on_error: bool = True to Process.close() and Thread.close(); teardown paths call close(raise_on_error=False).
• Make Process.close() idempotent when there is no handle and drop handle references even when CloseHandle fails.
• Add teardown-focused tests covering raising vs non-raising behavior and clean interpreter shutdown.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
tests/test_teardown.py	Adds regression and unit tests for destructor/teardown behavior and close() semantics.
MemLib/Thread.py	Adds raise_on_error option to Thread.close() and uses it from __del__.
MemLib/Process.py	Adds raise_on_error option + idempotent close behavior and uses it from __del__.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Borega]

Fixed in 19a46eb -- now states that False is only returned when raise_on_error is False, and that True also covers the already-closed handle.

[Borega]

Fixed in 19a46eb, same wording as Process.close().

[Borega]

Fixed in 19a46eb -- now text=True with errors="replace", so a code-page mismatch can't turn an assertion failure into a UnicodeDecodeError.

[Borega]

Rebased onto main — the conflict is resolved and this is mergeable again.

The conflict was with #9 (owns_handle), which landed in close() after this branch was cut. Both sides touched the same two spots; neither change was dropped:

• Docstring — kept the borrowed-handle paragraph from Make Process/Module/Thread hashable, add Process context manager, fix handle ownership #9 and appended the raise_on_error Args: entry.
• Body — the borrowed-handle early return from Make Process/Module/Thread hashable, add Process context manager, fix handle ownership #9 now runs before the CloseHandle call, so a borrowed handle is still released-but-not-closed and never reaches the new drop-reference/raise_on_error path. The ordering is _unregister_wait() → null handle → borrowed handle → CloseHandle.

Also folded in the Returns: clarification from the follow-up commit, since the two now interact: True means closed or already closed or borrowed-and-released; False only when raise_on_error=False and CloseHandle actually failed.

Full suite on the rebased branch: 184 passed, 2 skipped (the count grew because #5–#11 merged in the meantime), including the 7 tests/test_teardown.py cases.