the second-to-last line throwing an error can be fine, as long as it happens before the data is written to the database. More worrying would be if the last line caused an error, as that’s more likely to corrupt the data
the transaction hides the complexity, rather than removes it—the transaction adds some potential failure modes, even if it’s a net lowering of the total complexity
a transaction might not protect from overflows—it will depend a lot on the actual implementations
That being said, this is a good example of a real problem with a real solution, explaining an important concept—nice!
Thanks for the nits, cuz this kind of thing is all about nits! Agree with the first two, re your third one, it’s safeSub and safeAdd that would protect from overflows. Like the transaction, they’re more complex in the sense that their implementation is probably slower and more code, but simpler in the sense that they have a less constrained “safe space of operation”. (I am in search of a better term for that.)
A couple of nits:
the second-to-last line throwing an error can be fine, as long as it happens before the data is written to the database. More worrying would be if the last line caused an error, as that’s more likely to corrupt the data
the transaction hides the complexity, rather than removes it—the transaction adds some potential failure modes, even if it’s a net lowering of the total complexity
a transaction might not protect from overflows—it will depend a lot on the actual implementations
That being said, this is a good example of a real problem with a real solution, explaining an important concept—nice!
Thanks for the nits, cuz this kind of thing is all about nits! Agree with the first two, re your third one, it’s safeSub and safeAdd that would protect from overflows. Like the transaction, they’re more complex in the sense that their implementation is probably slower and more code, but simpler in the sense that they have a less constrained “safe space of operation”. (I am in search of a better term for that.)