Uncaught exception in runner-loader, "TypeError: n.cause?.hasOwnProperty is not a function"

```
Exception has occurred: TypeError: n.cause?.hasOwnProperty is not a function
at module.exports (C:\Users\Noah\.vscode\extensions\connor4312.nodejs-testing-1.6.3\out\runner-loader.js:1336:18)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async nextAsync (node:internal/streams/from:182:33)
```
https://github.com/connor4312/nodejs-testing/blob/7ad1de5ed9684be82032b1c1c184fd1e2a194132/src/runner-loader.ts#L119

...during test debugging. Most tests pass, but a handful fail with this error. These errors then cause the test run to never complete. It must be terminated which then trigger the following notification:

This most commonly occurs when comparing dynamic imports e.g.

...which actually proved to be somewhat useless and difficult to maintain, but was useful when comparing MJS exports to CJS exports when compatibility features were involved. Still, this was such an odd issue that I felt it should be reported despite being incredibly niche.

---

# Proposed Solution

Check if `error.cause` has the `hasOwnProperty' member and, to be safe, also check if `hasOwnProperty` is a function.

(this solution did not work when tested)

```ts
if (err.cause !== un&& 'hasOwnProperty' in err.cause && typeof err.cause.hasOwnProperty === 'function' &&
err.cause.hasOwnProperty('actual') && err.cause.hasOwnProperty('expected')) {
// ...
}
```

This should, in theory, allow any caught exception to be handled gracefully i.e. the same way the Assert exceptions are handled sans special formatting.

JavaScript, unfortunately, has very limited static typing (i.e. classes with mutable definitions). So, you have to use extremely verbose type-checking *at runtime* to ensure code will run as intended. Alternatively, use a framework like ArkType or Zod (they have tradeoffs other than performance).