Probabilistic Assertions: Crashing When Something Feels Wrong

http://www.spiteful.com/2008/04/14/crashing-when-something-feels-wrong/

by slackerIII • 18 years ago

24 8 18 years ago

Tichy2• 18 years ago

Maybe frequent backups would be a better solution?

pmjordan• 18 years ago

Backups are damage limitation, and yes, they are always a good idea. I would consider this kind of strategy not only damage limitation but also prevention, which is interesting.

palish2• 18 years ago

The "delete all of a user's files" example was just one of many. It is sometimes valid to force a crash when the code detects an impossible case (or when you choose not to recover from that case for simplicity). If each component either functions correctly or the program crashes, that can significantly reduce debugging time. There aren't any silent failures from components that simply ignore invalid input.

That said, with procedural languages I try to write code that recovers from all reasonable cases and assert the rest.

Tichy2• 18 years ago

What if the validation code itself contains the errors. It might be a fallacy to assume problems can be solved in that way.

blinks• 18 years ago

Yay for automated monitoring software. Nagios (http://www.nagios.org/) does this for networks (and is extendable for some other things). At my old job we used Hobbit (http://hobbitmon.sourceforge.net/) to watch our Java server instances (memory usage, etc.). There’s no reason why these monitoring programs couldn’t be used to monitor internal program statistics, as long as those stats were made available.

Generally you monitor from your internal network, and then provide some hook for the monitor to get information that’s only accessible from there. (SSH or a limited-access URL, etc.)

Monitoring programs are super-powerful and generally complex. Check them out — it’s a good skill to have when working with production software.

(I also posted this on the article.)

pmorici• 18 years ago

This sounds like circuit breakers for software. Instead of an over current condition you've got excessive busynesses.

angstrom• 18 years ago

I've worked with threshold logic like that for collecting and analyzing traffic on telephone switches where an alarm or notification would be generated if the threshold was broken.

Personally I would never want to debug something like that using a statistical probability that something might have gone wrong. Better to fail gracefully with something like multiple chains so that when a request chain goes down it gets logged, cleaned up, and recreated.

Worst case scenario they get a request timeout warning.

Probabilistic Assertions: Crashing When Something Feels Wrong

Related Stories