DEV Community: Kiara

Trying to Be Too Careful: Catching the Same Error Three Times

Kiara — Wed, 05 Aug 2026 23:50:31 +0000

One day I was wiring Supabase auth for a login page in one of my personal projects. I forced an error for manual testing — and got two error messages. That happened because the provider stored a message for the UI and the form still had its own failure path for the same rejection — so the same sign-in error was rendered twice.

No news. I’d seen that before. But for the first time, I actually stopped.

A login page is the most basic thing any developer eventually ships. I write it on autopilot now — and AI autocomplete is right there in the cockpit, cheerfully suggesting another try/catch. I’d been quietly replicating some bad habits with it.

Here’s what I had:

a service
a provider
a form
a lot of try/catch

Here’s what I didn’t have:

a contract for errors.

The autopilot `try/catch`

Most of us look at code that might fail and immediately wrap it in try/catch, throw something, and assume “the UI will handle it.”

In my auth flow, that looked like this:

Service — try/catch around the API call, throw on failure

(fair: something has to detect the external failure)

Provider — another try/catch, set state, throw again

(autopilot / copy-paste: “I should handle errors here too”)

Form — same energy again

(just in case)

Three layers touching the same error.

But who owns it? Are they throwing the same thing? What is the UI supposed to do with the same failure bouncing around three times?

That’s not carefulness. That’s a responsibility problem.

Before: everyone “handles” it

// provider — stores the message… and also wraps/rethrows
const signUserIn = async (email: string, password: string) => {
  try {
    await signIn(email, password)
  } catch (error) {
    setError('Error signing in: ' + (error as Error).message)
    throw new Error('Error signing in: ' + (error as Error).message, { cause: error })
  }
}

// form — touches the same failure again
const onSubmit = (data: LoginFormData) => {
  signIn(data.email, data.password)
    .then(() => navigate('/admin'))
    .catch((error) => {
      // second path for the same error (toast, local state, another throw…)
      throw new Error('Error signing in: ' + error.message, { cause: error })
    })
}

Same failure. Two owners. Messy contract.

Detect → Store → Display

If an error occurs, what must happen before the UI shows it?

Detect it
Store it (so the UI can read a stable message)
Display it

I started calling that split Detect → Store → Display:

Step	Layer
Detect	service
Store	context / provider
Display	UI

Responsibilities separated. Then the contract:

Pick one way the service signals failure — and stick to it.

throw or a result object ({ data, error }). Both work. Mixing both means whoever calls the service never knows what to check.

I went with throw. One path. Clear for callers.

How it looks now

// service — DETECT
export async function signIn(email: string, password: string): Promise<Session> {
  const { data, error } = await supabase.auth.signInWithPassword({ email, password })
  if (error) throw new Error(error.message, { cause: error })
  if (!data.session) throw new Error('No session returned')
  return data.session
}

// provider — STORE (+ rethrow so the caller still sees failure)
const signUserIn = async (email: string, password: string) => {
  setError(null)
  try {
    await signIn(email, password)
  } catch (err) {
    setError(err instanceof Error ? err.message : 'Sign in failed')
    throw err // same error — don't wrap it again
  }
}

// UI — DISPLAY
{error && <p role="alert">{error}</p>}

// form — no second error owner; just await success vs failure
const onSubmit = async (data: LoginFormData) => {
  try {
    await signIn(data.email, data.password)
    navigate('/admin')
  } catch {
    // message already stored in context
  }
}

The form doesn’t need to “handle” the error again. It just renders what the provider already stored.

Same rule, elsewhere in the app

Auth was where I noticed the mess — but the useful part is that Detect → Store → Display isn’t an “auth pattern.”

In the same project, registration already talks to Supabase through a service and surfaces failure through hook/UI state (in that flow, React Query helps with the “store” side). Once I named the contract, the question got simpler everywhere:

Does the service only detect and throw?
Does one state layer own the message?
Does the UI only display — without catching and re-throwing the same failure?

I don’t need a different philosophy per feature. I need the same contract so I’m not “extra careful” in three places and clear in none.

What I got out of it

a fail path I can actually read
layers with a clear job
one message, one owner
a rule I can reuse on the next form, not only on login

And just like that, I quit being a “way too careful, but not so much” coder — the kind who wraps everything in try/catch and still doesn’t know who owns the failure.

Careful isn’t more catches.

Careful is a contract.

I put my entire CRUD in one React hook. It felt efficient. Then it wasn’t.

Kiara — Wed, 29 Jul 2026 02:40:49 +0000

They say every bad decision comes from a good intention.
I'd say it comes from good intentions… and a little lack of thinking things through.
This is the story of the day I put my entire CRUD inside one React hook — and how that backfired.

The good intention

I needed a simple admin panel: list, create, read, update, delete. Classic CRUD.
What I wanted to avoid:

lots of files and boilerplate
a hard time managing state
splitting every action into its own file (felt like overengineering for "just a screen")

So I built useItems: one hook for the whole feature.

Where I didn't think it through

I was already using React Query — so I wasn't really fighting state the hard way. React Query is that layer.
And yes, the screen was simple — but it lived inside a complex app that was going to grow. I optimized for the afternoon, not for the next six months.
Still, I went ahead. Into the hook went:

a list query (with filters)
a find-one-by-id query
all mutations: create, update, delete It looked roughly like this:

export function useItems(
  id?: number,
  filters?: Partial<ItemsQuery>,
) {
  const api = useFetch();

  const listQuery = useQuery({
    queryKey: ["items", filters],
    queryFn: () => api.get("/items", { params: filters }),
  });

  const detailQuery = useQuery({
    queryKey: ["item", id],
    queryFn: () => api.get(`/items/${id}`),
    enabled: !!id,
  });

  const createMutation = useMutation({
    mutationFn: (body: CreateItemBody) => api.post("/items", body),
  });

  const updateMutation = useMutation({
    mutationFn: ({ id, body }: { id: number; body: Partial<UpdateItemBody> }) =>
      api.patch(`/items/${id}`, body),
  });

  const deleteMutation = useMutation({
    mutationFn: (id: number) => api.delete(`/items/${id}`),
  });

  return {
    items: listQuery.data?.items,
    total: listQuery.data?.total,
    item: detailQuery.data,
    create: createMutation.mutateAsync,
    update: updateMutation.mutateAsync,
    remove: deleteMutation.mutateAsync,
    isLoadingList: listQuery.isLoading,
    isLoadingItem: detailQuery.isLoading,
    isCreating: createMutation.isPending,
    isUpdating: updateMutation.isPending,
    isDeleting: deleteMutation.isPending,
  };
}

Clean. Convenient. Slightly cursed.

Why it was a bad decision

Different lifecycles, one hook.
You can see it in the parameters alone: id and filters. A list, a detail, and a write path are three jobs. I forced them through one door.
Cache keys and invalidation fog.
Ironically, I got the pain I tried to avoid: things felt hard to control again. The list refetched when I was only editing one item — or didn't refetch after a delete. I'd invalidate wider "to be safe," make everything heavier, then invalidate differently. React Query wasn't broken. My boundary was.
Fake reuse.
"Reusable" became "configurable." Need only the modal update? Still mount the feature — just flip enabled flags and hope. That's not reuse. That's a monolith with dimmer switches.

The symptoms

I didn't notice because of architecture theory. I noticed because the UI started arguing with me.

Invalidations with a personality — list reloading at the wrong time, or not when it should
Unnecessary weight — detail pages and update modals dragging list-query energy they never needed
Rerenders. Oh my god, the rerenders The sentence that finally clicked: > This isn't reuse. It's a module disguised as a hook.

What I should've done

Split by intention: list hook, detail hook, small mutation hooks next to the UI that writes. Shared query keys stay small. Screens import only what they need.

// before — every screen dragged the whole feature
const { items, item, update, remove, isLoadingList, isLoadingItem } =
  useItems(id, filters);
// after — imports = intention
const { items, isLoading } = useItemsList(filters); // table
const { item } = useItem(id); // detail
const { mutateAsync: updateItem } = useUpdateItem(); // modal / form

Less clever. Much calmer.

Results

clearer imports (the screen says what it cares about)
fewer surprise refetches
lighter modals and pages

And a reusable lesson: good intentions need an expiry date.

But, to be fair: a monolith hook isn’t always a crime. For a quick prototype or a tiny CRUD that will stay tiny, one useItems can be the honest move — less ceremony, faster shipping. The mistake wasn’t the pattern itself. It was treating a prototype-shaped abstraction like it could scale inside a growing app without revisiting the boundary.

If you've also built a useSomething that returned twelve things and a prayer… hi. We're the same.