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- Dev Diligence: Don’t Invest in the Wrong Code
- Crashing When Something Feels Wrong
- Housekeeping
- Things That Are Important: Where Clauses
- Programmer’s Toolbox Part 3: Consistent Hashing
- The Lawsuit, Shutdown, and Aftermath
- Users With a Tattoo of Your Logo? Check.
- Always Refer to Your V1 As a Prototype
- Lessons Learned Scaling the Audiogalaxy Search Engine
- Design details of Audiogalaxy.com’s high performance MySQL search engine
Archives
Categories
- Audiogalaxy (7)
- Dev Diligence (1)
- Toolbox (3)
- Uncategorized (3)
Tag Cloud
- /dev/epoll
- Assertions
- Audiogalaxy
- Berkeley DB
- Bloom Filters
- C
- Caching
- Compression
- consistent hashing
- Dev Diligence
- dynamo
- FolderShare
- History
- Inverted Index
- Managing Gigabytes
- memcached
- Message Passing
- Monitoring
- MS Manners
- MySQL
- partitioning
- RIAA
- scalability
- Search
- Skip Lists
- Soft Deletes
- Startup Lessons
- startups
- STS
- Toolbox
- Unrolled Linked Lists
- VEB Trees