try, catch, finally

try takes a block of code that might throw. catch takes a name for whatever was thrown and a block to run instead of the rest of the try block. finally takes a block that runs either way. You need try plus at least one of the other two; all three together is common and all three are independent.

The name in catch is optional. If the block never looks at what was thrown you can write catch with no parentheses at all, and that is more honest than declaring a variable you never read.

One try statement can wrap one line or two hundred. Wrapping one is nearly always better: the smaller the try block, the more precisely you know what the catch block is apologising for.

This is the misunderstanding worth killing early. Catching an error does not undo anything. It is not a transaction, and there is no rollback.

Everything the try block managed to do before it threw has still been done. Variables it set are still set. Items it pushed onto an array are still on the array. A message it already sent has been sent. What catch gives you is control of what happens next, and nothing else.

So the question a catch block has to answer is not can I undo this but what is true now, and what should I do about it. Sometimes that means cleaning up by hand, which is what finally is for.

finally runs when the try block finishes normally. It runs after a catch block handles an error. It runs when the try block returns, before the caller receives the value. It runs when an error is passing through on its way out with no catch block at all.

That is what makes it the right home for cleanup: closing something you opened, releasing something you locked, stopping a spinner, counting an attempt. Written once in finally, it happens on paths you have not thought of yet, including the ones somebody adds next year.

The ordering is worth saying out loud, because it surprises people: a return inside try does not leave immediately. The value is computed, then finally runs, and only then does the caller see the value.

Because finally runs on the way out, a return inside it replaces whatever was on its way out. A function whose try block returns "the answer" and whose finally block returns "the cleanup" returns "the cleanup".

The same applies to errors: a return inside finally will discard an error that was passing through, so the caller sees a perfectly ordinary return value where there should have been a failure. That is a silent failure created by a line of cleanup code, and it is very hard to find.

The rule that avoids all of this: never return, throw, break or continue from inside a finally block. Do cleanup there and nothing else.

catch (error) {} is a sentence in English. It says: I know this can fail, I have thought about it, and continuing as though it had not is the correct behaviour.

Almost every empty catch block in the world is a lie. It was written to make a red message go away during development and it stayed. The failure it hides does not go away; it becomes a bug report months later that nobody can reproduce, because the one place that knew what happened chose not to say.

A useful discipline: if you write an empty catch block, write the comment that justifies it on the same screen. If you cannot write the comment, you do not want the empty catch block — you want a log line, a fallback with a stated reason, or no catch at all.

A catch block does not have to handle everything it receives. It can handle the one kind of failure it understands and throw the rest onwards with a bare throw error, which passes the original object along untouched: same name, same message, same stack.

This is what turns catch from a net into a filter. A function that knows how to cope with a missing file has no idea what to do about a bug in its own arithmetic, and pretending otherwise turns the bug into a wrong answer.

If you want to add context on the way past, throw a new error with cause set to the original, as in lesson two. What you must not do is throw a new error without the cause, because then the sentence you added has replaced the information somebody actually needed.

A catch block catches every value thrown anywhere inside its try block. That includes values thrown by code you did not write, values that are not errors at all, and — the one people forget — errors thrown by your own guard clauses a few lines above.

That last case bites hard. You validate an input inside a try block and throw a careful TypeError; two lines later your own catch block turns it into a default value, and the validation you were so pleased with has no effect whatsoever.

So a catch block that does anything other than report should test what it caught. error instanceof SyntaxError, or a check on error.name, turns an indiscriminate net back into a deliberate decision.