3 ms·
Not quite! I don't think that's what they're getting at. The idea is this: Say you have a record A with fields f1, f2, f3. When an even comes in you run a func
by kjeetgill 8y ago
Not quite! I don't think that's what they're getting at.
The idea is this: Say you have a record A with fields f1, f2, f3. When an even comes in you run a function F with steps s1, s2, s3 each of which may modify a field of record A.
Here's the issue, if s3 fails (due to "invalid input"), the modifications to A from s1 and s2 are incorrect and A is now corrupt.
There are a bunch of ways to handle this but the one described here is to avoid touching data that persists between requests until you're at a stage where nothing can fail anymore.
- kilburn 8y ago> until you're at a stage where nothing can fail anymore. ... and then there's a NullPointerException because you forgot to check something that could indeed fail (i.e.: you have a bug). In other words: they advise you to not have bugs in that part of the codebase, which was precisely my objection.
- kjeetgill 8y agoAbsolutely. But doing things in this style protect you from large classes of the especially hard to reproduce bugs. Nothings perfect but it helps a lot! I'd never heard it articulated before but I personally discovered this style over the years as well.