#118 / #280 — the leak-free, main-bundle error thrown when createCausl() cannot reach the wasm engine because the @causl/causl-wasm-ts/wasm subpath was never imported (the registration slot is undefined). Carries the stable 'CAUSL_WASM_ENGINE_UNAVAILABLE' code — the SAME discriminant adopters branch on for the subpath's WasmEngineUnavailableError family — so a consumer's catch is uniform regardless of WHERE the loud fail originated. The name is aligned to the subpath's family for readable logs; the class identity differs only because the main bundle must not name a @causl/causl-wasm-ts/wasm symbol (the bundle-no-wasm-leak gate — each e2e/bundler-interop fixture's verify.mjs). When the subpath IS imported, the loud throw comes from the subpath's own WasmEngineUnavailableError / CauslWasmNotPreloadedError instead (see createWasmExplicitOrThrow).

causl/causl-wasm-ts#363 finding 8 — extends CauslError, like every other error this package throws. It used to extend plain Error, while the subpath's twin (wasm/index.ts) extended CauslError, and the asymmetry was observable:

row 1 (subpath never imported) -> e instanceof CauslError === false row 2 (imported, not preloaded) -> e instanceof CauslError === true

so the handler src/errors.ts teaches — catch (e) { if (e instanceof CauslError) renderEngineError(e); else throw e } — handled the not-preloaded case and RETHREW on the never-imported one, which is the hardest of the three to reproduce in dev (it needs a bundler that tree-shook the /wasm import) and the one the handler drops. src/errors .ts is main-bundle and names no wasm symbol, so extending it leaks nothing: the bundle-no-wasm-leak gate greps for loadWasmBackend / WasmBackendUnavailableError (e2e/bundler-interop/*/verify.mjs) and neither appears here.

— observable on the err.code an adopter catches.

Hierarchy (View Summary)

Constructors

Properties

cause?: unknown
code: "CAUSL_WASM_ENGINE_UNAVAILABLE" = ...
message: string
name: string = 'CauslError'
stack?: string
stackTraceLimit: number

The Error.stackTraceLimit property specifies the number of stack frames collected by a stack trace (whether generated by new Error().stack or Error.captureStackTrace(obj)).

The default value is 10 but may be set to any valid JavaScript number. Changes will affect any stack trace captured after the value has been changed.

If set to a non-number value, or set to a negative number, stack traces will not capture any frames.

Methods

  • Creates a .stack property on targetObject, which when accessed returns a string representing the location in the code at which Error.captureStackTrace() was called.

    const myObject = {};
    Error.captureStackTrace(myObject);
    myObject.stack; // Similar to `new Error().stack`

    The first line of the trace will be prefixed with ${myObject.name}: ${myObject.message}.

    The optional constructorOpt argument accepts a function. If given, all frames above constructorOpt, including constructorOpt, will be omitted from the generated stack trace.

    The constructorOpt argument is useful for hiding implementation details of error generation from the user. For instance:

    function a() {
    b();
    }

    function b() {
    c();
    }

    function c() {
    // Create an error without stack trace to avoid calculating the stack trace twice.
    const { stackTraceLimit } = Error;
    Error.stackTraceLimit = 0;
    const error = new Error();
    Error.stackTraceLimit = stackTraceLimit;

    // Capture the stack trace above function b
    Error.captureStackTrace(error, b); // Neither function c, nor b is included in the stack trace
    throw error;
    }

    a();

    Parameters

    • targetObject: object
    • OptionalconstructorOpt: Function

    Returns void