[Enhancement] : Add transparent error recovery for state updates and derived computations

[jiji-hoon96]

Problem

Currently, errors in setState or derived computations cause the entire update chain to halt, potentially leaving the application in an inconsistent state

// If updater throws, state becomes inconsistent
setState = (updater: TUpdater) => {
  this.prevState = this.state
  this.state = (updater as any)(this.prevState) // 🚨 throws, state corrupted
  this.options?.onUpdate?.() // never called
  __flush(this as never) // never called
}

// If computation throws, entire dependency chain stops
recompute = () => {
  this.state = this.options.fn({ ... }) // 🚨 throws, chain halts
}

How other libraries handle this

Zustand

// By default, the error is thrown as is
const useStore = create((set) => ({
  count: 0,
  increment: () => set((state) => {
    if (someCondition) {
      throw new Error("Update failed") // 🚨 throw as is
    }
    return { count: state.count + 1 }
  })
}))

// Error handling with middleware
const useStore = create(
  devtools(
    (set) => ({ ... }),
    { 
      name: "store",
      onError: (error) => console.error(error) // Only error logging
    }
  )
)

• Errors propagate naturally (no built-in recovery)
• Optional error handling via middleware
• Focuses on simplicity - lets users handle errors explicitly

Jotai

// If an error occurs, it propagates to the Error Boundary.
const countAtom = atom((get) => {
  const data = get(dataAtom)
  if (data.error) {
    throw new Error("Computation failed") // Error Boundary catch
  }
  return data.value * 2
})

// Manage error states as separate atoms.
const errorAtom = atom(null)
const safeCountAtom = atom(
  (get) => {
    try {
      return get(countAtom)
    } catch (error) {
      set(errorAtom, error) // Saving error states
      return 0 // fallback value
    }
  }
)

• Computation errors propagate to Error Boundaries
• Provides error atoms for explicit error state management
• Maintains atom dependency graph integrity even when errors occur

Proposed Approach

• Rollback on error: If setState fails, revert to previous state
• Preserve dependency chain: If derived computation fails, keep previous value
• Optional error callbacks: Let users opt into custom error handling
• Development warnings: Log errors in dev mode

// Example: transparent rollback
setState = (updater: TUpdater) => {
  const prevState = this.state
  try {
    this.prevState = this.state
    this.state = (updater as any)(this.prevState)
    this.options?.onUpdate?.()
    __flush(this as never)
  } catch (error) {
    // Transparent recovery: rollback state
    this.state = prevState
    this.options?.onError?.(error) // optional user handling
    if (process.env.NODE_ENV === 'development') {
      console.warn('Store update failed, rolled back:', error)
    }
  }
}

This keeps the library simple while preventing production crashes from state inconsistency.

Questions

Should error recovery be opt-in or default behavior?
Any concerns about try-catch performance overhead?
Should we preserve error information for debugging?

If you need clarification on how other state management libraries (recoil, redux, etc.) handle errors, please feel free to ask.
And if you have any questions about the methods I've presented, feel free to ask!

I don't know exactly what you're aiming for with tanstack-store, so it's hard to make suggestions.