When software developers update their software to include new configuration options, they have a bunch of options to pick from, of how to handle installs running on the old options.
For example, you could
- automatically update config
- document a process to gracefully update config
- Give human readable errors showing what changes you need to make to conifg
- Break the application with a super cryptic error message, and refuse to start until config is wiped with ‘new’ default config.
…
Why do developers keep picking 4? At least 2 horribly complex bits of software in the past year have decided to do that to me, which cost me a few days of head-bashing-against-desk trying to work out what was broken time. 🙁
May not be conscious, could be the result of insufficient QA and regression testing. The developer could be testing in ideal conditions and not seeing such errors. It’s incredibly frustrating though. Software rarely gets the regression testing it needs, because it’s hard. When you find this stuff, file bug reports, document what you’d like to happen.
I’m currently most proud of a caught socket timeout exception in my code that tells the user what config timeout variable to increase. 🙂
That however is the only error I’ve recently handled like that, but it won’t be the last.