3 ms·
> which if you're a good coder would also involve some try/catch and proper fallback behavior in case of an error It's actually really hard to do so correctly
by anarazel 8y ago
> which if you're a good coder would also involve some try/catch and proper fallback behavior in case of an error
It's actually really hard to do so correctly in the face of concurrency. Do not attempt to do so unless you've a really good reason.
- jedberg 8y agoI would say in this day of high scalability and microservices, a good engineer should be skilled at dealing with these types of errors, as they would be one of the most common types. Edit: I find it interesting that this comment has fluctuated between -2 and +2 points. Apparently saying that engineers should be able to handle concurrency errors is controversial?
- anarazel 8y agoI bet that at least 9/10 experienced engineers in the space will come up with a solution that has at least one of a) incorrect behaviour under concurrency b) unnecessary deadlocks c) extreme slowness d) break w/ triggers, row level security etc.
- anarazel 8y ago> Apparently saying that engineers should be able to handle concurrency errors is controversial? I didn't vote either way. But perhaps it's less the fact that they should be able to handle concurrency, and more that replicating the necessary non-trivial logic in several applications isn't a good plan.