Preserve plain-object rejection reasons in global error handlers

[FeironoX5]

Closes #171

Fix global error normalization so plain-object promise rejection reasons are captured as readable payloads instead of "[object Object]".

PR Description

Fix error normalization for global error handlers so rejected plain objects are preserved instead of being collapsed into "[object Object]".

This PR introduces a normalized CapturedError shape and uses it across the main catcher and console catcher. For unhandledrejection, plain-object reasons are now serialized into a readable title instead of going through String(obj). For browser ErrorEvents, the catcher now also builds a more useful fallback message when the original error object is unavailable (for example, cross-origin script errors).

Changes

• Added fillCapturedError and getErrorFromErrorEvent helpers in src/utils/error.ts
• Switched Catcher internals from Error | string to normalized CapturedError
• Reused normalized error extraction in consoleCatcher
• Preserved original rawError reference for deduplication/backtrace logic
• Added tests for:
  • Error
  • DOMException
  • plain-object promise rejection reasons
  • string / null / undefined rejection reasons
  • circular objects
  • cross-origin-style ErrorEvent fallback

[FeironoX5]

it will be simpler

[neSpecc]

Suggested change

	private async prepareErrorFormatted(error: ErrorSource, context?: EventContext): Promise<CatcherMessage<typeof Catcher.type>> {
	private async prepareErrorFormatted(errorOrRejectionReasion: ErrorSource, context?: EventContext): Promise<CatcherMessage<typeof Catcher.type>> {

[neSpecc]

specifying of fallback title and type is a part of internal business logic of getErrorFromErrorEvent. It should not be exported

[neSpecc]

reason is not an error

[neSpecc]

maybe it should return only type, title, backtrace?

const { type, title, backtrace } = getErrorDetailsFromEvent(event);

[Reversean]

rawError is typed as unknown, so casting to Error before accessing .stack is unsafe — the cast bypasses the type system without any runtime guarantee. The optional chain prevents a throw but silently produces undefined for non-Error values.

Prefer an explicit guard (same fix applies on line 222):

stack: errorSource.rawError instanceof Error ? errorSource.rawError.stack ?? '' : '',

[Reversean]

Shouldn't we use here const type from 202 line?

[Reversean]

I know that it's no-op, but event = event as ErrorEvent reads ike mutation. Perhaps it'll be better to bind a local const:

const errorEvent = event as ErrorEvent;
return {
  rawError: errorEvent.error,
  fallbackTitle: ...,
};

Same for unhandledrejection branch.

[Reversean]

When rawError is an Error (e.g. Promise.reject(new TypeError('...'))), getTypeFromError returns 'TypeError' and fallbackType: 'UnhandledRejection' is silently discarded.

Previously, type was always the error's own name for Error objects – so this is not a regression – but it's a non-obvious, especially since the console catcher diverges here (see consoleCatcher.ts:220).

Perhaps we should leave comment explaining current behavior.

[Reversean]

Two cases worth adding to this describe block:

1. Sanitized DOMException — Sanitizer.sanitize converts it to a string placeholder ('<instance of DOMException>'), so getTypeFromError returns undefined. The getTitleFromError suite already covers this input, but getTypeFromError doesn't:

it('should return undefined for sanitized DOMException', () => {
  expect(getTypeFromError(Sanitizer.sanitize(new DOMException('Network error', 'NetworkError')))).toBeUndefined();
});

2. Plain object with a name field — some libraries reject with { name, message } shapes; this is the path that returns a non-undefined type from a plain object:

it('should return name from plain object with name field', () => {
  expect(getTypeFromError(Sanitizer.sanitize({ name: 'CustomError', code: 42 }))).toBe('CustomError');
});