new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Vue · all subjects

error-handling

14 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Production error codes replace full error messages

In production builds, error handler APIs receive a short error code instead of the full information string as their 3rd argument. This applies to app.config.errorHandler, onErrorCaptured (Composition API), and errorCaptured (Options API).

Runtime error codes reference

Production builds use short error codes for runtime errors. The codes map to original full information strings and are used in error handler APIs instead of verbose error messages.

Compiler error codes in production

Compiler errors in production builds also use short error codes that map to their original full error messages.

app.config.errorHandler receives error codes

The app.config.errorHandler API receives short error codes instead of full error messages as the 3rd argument in production builds.

errorCaptured receives error codes in production

The Options API errorCaptured hook receives short error codes instead of full error messages as the 3rd argument in production builds.

onErrorCaptured() signature and type

onErrorCaptured(callback: ErrorCapturedHook): void where ErrorCapturedHook = (err: unknown, instance: ComponentPublicInstance | null, info: string) => boolean | void. It registers a hook to be called when an error propagating from a descendant component has been captured.

onErrorCaptured() error sources

Errors can be captured from: component renders, event handlers, lifecycle hooks, setup() function, watchers, custom directive hooks, and transition hooks.

onErrorCaptured() callback arguments

The hook receives three arguments: the error (err: unknown), the component instance that triggered the error (instance: ComponentPublicInstance | null), and an information string specifying the error source type (info: string). In production, the info argument will be a shortened code instead of the full information string.

onErrorCaptured() error state rendering warning

The error state should not render the original content that caused the error; otherwise the component will be thrown into an infinite render loop.

onErrorCaptured() return value to stop propagation

The hook can return false to stop the error from propagating further.

onErrorCaptured() propagation to app.config.errorHandler

By default, all errors are still sent to the application-level app.config.errorHandler if it is defined, so that these errors can still be reported to an analytics service in a single place.

onErrorCaptured() multiple hooks propagation order

If multiple errorCaptured hooks exist on a component's inheritance chain or parent chain, all of them will be invoked on the same error, in the order of bottom to top. This is similar to the bubbling mechanism of native DOM events.

onErrorCaptured() when hook itself throws

If the errorCaptured hook itself throws an error, both this error and the original captured error are sent to app.config.errorHandler.

onErrorCaptured() returning false prevents further propagation

An errorCaptured hook can return false to prevent the error from propagating further. This is essentially saying 'this error has been handled and should be ignored.' It will prevent any additional errorCaptured hooks or app.config.errorHandler from being invoked for this error.

Give your agent this brain