UI Design Theory

When is it acceptable for a program to take a shit?  I mean, I’ve learned in my MIS courses throughout high school and in lots of app design theory books that programs should be capable of recovering gracefully from any kind of possible unexpected situation.  But how far does one take that?

Case in point:  A filesystem walker.  Should I spend the extra time to build in error-detection code for any and all of the 31 illegal characters in filenames under ext2 (3, 4)?  Or should I assume that if someone’s running an FS walker, the filesystem is sufficiently intact as to not have files with 0x0f (bitshift left) characters in them?  And what’s considered an acceptable way of handling them?  Say it did encounter a broken inode entry – what should it do, ignore it, print a warning, choke and die?  I guess what I’m asking is what are the acceptable levels of robustness in small utility apps these days?

Advertisements
  1. #1 by Andrew D. on February 19, 2010 - 12:42 PM

    Most of the Linux community has the “one purpose for one application” mentality. If it’s a feature that something else already installed on a user’s computer can take care of, don’t bother covering that scenario.

    If it encounters a broken inode, ignore it and move on. Let fsck handle a broken inode on reboot.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: