Error paths: deciding what happens when the entry is wrong

When a function gets input it cannot work with, the first question is who made the mistake. A person typing into a form who left the title blank has done something entirely expected - forms get filled in badly all day long, and your library's job is to say what is missing so it can be fixed. A programmer who calls createSession with the string 'thirty' where a number belongs has written a bug; no amount of politeness at runtime will fix their code.

Those two deserve different treatments, and mixing them up is what makes error handling feel like guesswork. Expected failure - bad data from outside - is a result: you hand back a report saying what is wrong, and the caller shows it to the person. A bug in the calling code is not a result: you throw, loudly, so it cannot be ignored and the stack points at the line that did it.

readlog needs both, and they are two separate functions on purpose. validateSession reports. createSession enforces. Keeping them apart means the reporting can be tested without catching anything, and the enforcing is three lines.

This is the same gate as lesson 2, doing its other job. The boundary is wherever data crosses from a place you do not control into your library. Everything outside is suspect; everything inside has been checked. Where exactly you draw that line is a design choice, but there must BE a line, and it must be somewhere you can point at.

The failure mode without one is defensive code everywhere: every function testing its arguments, and every one of them slightly differently. It doubles the size of the code, it hides the actual behaviour among the checks, and it still misses cases, because there is no single place responsible for saying what a valid session is.

With a boundary, the middle of the library is written as if the data were always fine - because past the gate it is. That is not optimism, it is where the checking happens being written down.

The lazy validator returns as soon as it finds a problem. The person fixes it, resubmits, and is told about the second problem. Fix, resubmit, third problem. Three rounds where one would have done, and each round feels like the software is toying with them.

So collect. Start an empty array of messages, test each rule, push a message for every rule that fails, and at the end report whether the array is empty. The whole validator becomes a flat list of if statements with no early returns, which also makes it trivial to read: one rule per if, in the order the fields appear.

There is one legitimate early return, and it is the shape check. If the thing handed in is not an object at all, every field test after it would throw rather than report - so that check comes first and, when it fails, it is the only message there is. Checking for null explicitly matters here, because typeof null is famously 'object'.

'Invalid input' is useless. It tells the reader that something is wrong and leaves them to find out what, which is exactly the work they needed help with. A good message names three things: which field, what the rule is, and - when it is safe to show - what arrived instead.

'pages must be a number of 0 or more' names the field and the rule. Adding the value, as the second worked example does, turns it from a rule you have to interpret into an observation you can act on: got '30' with the quotes right there tells you the form sent text where a number belongs.

Keep the wording of a message stable, because things depend on it - your own tests, and sometimes a caller matching on it. Changing 'title must be a non-empty string' to 'the title is required' is not a cosmetic edit; it is a change to your library's behaviour, and it belongs in the same category as changing a return value.

Module 7 gave you both tools. The choice between them comes down to one question: can the caller reasonably do something about this? If yes - bad form data, a file with a rubbish line in it - return a value describing the failure, because handling it is normal work, not an emergency. { ok: false, errors: [...] } is a result like any other, and the caller can show it, log it, or skip that row.

If no - the call itself is wrong, the arguments make no sense, continuing would produce a silently wrong answer - throw. Throwing is the loud option, and its loudness is the feature: nobody can ignore it by forgetting to check a field, which is exactly how a returned failure gets missed.

Notice that the same badness can deserve both treatments in different functions, and readlog does exactly that. validateSession reports on a blank title, because reporting is its whole job. createSession throws on the same blank title, because building a record from an entry you were told is invalid would put nonsense into the middle of the library. One rule, two responses, chosen by what each function is for.

The obvious check for a numeric field is typeof value === 'number', and it has a hole in it. When a conversion fails - Number('twelve'), for instance - the result is NaN, which stands for not-a-number and whose typeof is, unhelpfully, 'number'. So the check passes, the value flows into your totals, and every sum that touches it becomes NaN as well. The log reports nothing at all and nothing in the code looks broken.

Number.isFinite is the check that closes the hole. MDN is explicit that it does not convert its argument first: only values that are already numbers, and finite, come back true. NaN is false. Infinity is false. The string '42' is false - which is the right answer for a validator, because text is not a number no matter how numeric it looks.

Watch out for the other conversion trap while you are here: Number('') is 0, not NaN. An empty box in a form therefore becomes a perfectly valid zero if you convert before you check. Convert where you have decided text is acceptable, check where you have decided it is not, and never let the two happen in the same breath.

Bad data from outside is expected and gets reported; a wrong call from other code is a bug and gets thrown. Check at one boundary so the middle of the library can stop defending itself. Collect every broken rule in one pass, with a single early return for 'this is not an object at all' - remembering that typeof null is 'object'. Name the field, the rule and, where it helps, the value. And use Number.isFinite rather than typeof, because typeof NaN is 'number' and NaN spreads through every total it touches.