I’m sort of lazy, so I really like the idea of code that continually checks itself by using assertions. I even like running production services with assertions turned on. To be clear, I’m talking about assertions that check for actual bugs in your code – not assertions that socket() didn’t fail. Still, crashing production servers is a contentious issue, but sometimes (hopefully rarely) it is the best thing to do. For something like FolderShare, crashing a server as soon as there is any hint of an error is vastly safer than possibly deleting someone’s files due to a bug. Of course, this introduces the risk that you could have multiple servers fail in a short amount of time, but you need to design for that case anyway.
Search
About
You are currently browsing the Spiteful.com weblog archives for 'assertions' tag.
Latest
RSS- Where Are the AB Testing Frameworks?
- Two and a Half Months of Twitter
- Next Gen Productivity Monitoring Software
- Netflix Prize Concept + Google 411 Data
- Handling Human Error In the Datacenter
- tklein on twitter
- Dev Diligence: Don’t Invest in the Wrong Code
- Crashing When Something Feels Wrong
- Housekeeping
- Things That Are Important: Where Clauses
Categories
- Audiogalaxy (4)
- Dev Diligence (1)
- Neat Ideas (2)
- Toolbox (3)
- Uncategorized (7)
Interesting Stuff
Tag Cloud
- /dev/epoll
- Assertions
- Audiogalaxy
- Berkeley DB
- Bloom Filters
- consistent hashing
- Dev Diligence
- dynamo
- FolderShare
- History
- ideas
- intolerance
- memcached
- Message Passing
- MS Manners
- MySQL
- partitioning
- prizes
- productivity
- RIAA
- Skip Lists
- Soft Deletes
- Startup Lessons
- startups
- STS
- Toolbox
- Unrolled Linked Lists
- uptime
- VEB Trees