Overview

This chapter is the fourth category, following "Optimization," "Testing," and "Store Design."

Errors happen — a network request fails, a user submits malformed input, a third-party API returns something unexpected. Where and how you handle those errors is left to the developer; Stores and Components are plain classes, and nothing in the framework automatically catches an exception and swaps in a fallback UI on your behalf. This chapter covers where to put error-handling logic so that a single failure degrades gracefully instead of leaving the application in a broken, half-rendered state — and how to find and fix the kind of bug that doesn't throw at all: a leaked reference that quietly keeps memory alive.

Questions Addressed in This Category

• How should a Store expose the result of a fallible asynchronous operation, so components can react to failure the same way they react to any other state change?
• What happens when an exception is thrown from inside a lifecycle hook such as created() or onAfterRender(), and how should that be handled safely?
• How do you detect and track down a memory leak caused by a missing dispose() call?

info

This chapter assumes familiarity with the Store and Component lifecycle, and with the patterns covered in Store Design.