Дело это неблагодарное, но отнюдь не бесполезное. В последнее время стал замечать забавные вещи связанные с ним.

Во первых это уже не только способ зафиксировать программерскую мысль в коде.
Во вторых даже казалось бы банальнейшая функция в 3 строчки с первого взгляда, на самом деле может быть не такой уж и простой. Пример к сожалению в голову не приходит. Домашнее задание - подумать на досуге
В третих способ кодирования. Вот про это я и хочу написать.

Существуют различные подходы и методологии к кодированию. На ум приходит:
1. test driven development
2. процедурное программирование а-ля old school C
3. какое то такое: http://habrahabr.ru/blogs/crazydev/38612/
ну и наверное ещё с десяток наберёться. Собственно всё это и вот это: http://community.livejournal.com/ru_java/704111.html?style=mine навели меня на забавный подход при кодировании (немного даже проектировании) систем.

Принцип параноидальной отказоустойчивости.

Собственно в чём он заключается. Есть некий основной бизнес процесс. Он как то реализуется какими то способами. НО. При при кодировании этого бизнес процесса выполняюся следующие правила:
1. Всегда выполнять проверку входных параметров (для системы/модуля/класса/пр.)

2. Если какие то параметры не удовлетворяют необходимым, то попытаться их интерпретировать как нужные. Первый пример который пришёл в голову: HTTPServletRequest.getParameter("id"). Всегда возвращает String, ибо специфика технологии. Однако в контексте бизнес процесса этот параметр должен быть числом. Поэтому логично его конвертировать в Integer. Что будет если входной параметр будет: blah123? Правильно! Exception. Однако согласно второму пункту правил программа интерпретирует такой входной параметр как 123. Конечно это не правильно с точки зрения протокола, поэтому в таких случаях можно логировать неправильные запросы с уровнем warning или error - тут уж как договориться

3. Динамическая реконфигурация. Обычно система каким то образом конфигурируется. Однако все мы люди и поэтому очень часто возникают ошибки конфигурации. Поэтому суть положения заключается в том чтобы программа при своём запуске (единожды) анализировала входные параметры конфигурации и изменяла их при необходимости. Что подразумевается? Допустим входной параметр это url который будет подставляться в генерируемые ссылки на картинки. Если он будет некорректен, то это случай 1или2. Однако если он корректен, но допустим ведёт на внутреннее имя сервера - например myserver - (и при этом извне это имя не будет доступно так как не прописано в dns-серверах интернета) то приложение должно автоматически это определять и изменять его на внешнее имя по которому доступен этот сервер например somehost.ru.

Так же сюда можно отнести всевозможные системы с автоконфигурацией. Например системы отправки сообщений должны на основе скорости ответа от получателя сообщений автоматически определять оптимальную скорость посылки сообщений в секунду и, в случае более быстрой отправки, перераспределять системные ресурсы.
Также автоконфигурирование может заключаться в автоматическом поиске сервисов зарегистрированных в сети. (подоходы и средства такие как JNDI, SOA вполне могут направить в правильную сторону )

Вообще при конфигурировании приложений созданных по принципу параноидальной отказоустойчивости нужно следовать простому правилу: если что то можно сконфигурировать автоматически то это нужно сделать автоматически.

4. Параноидальная обработка exceptions. Как обычно происходит обработка например IOException? Правильно! "Файл не найден. Попробуйте указать другое имя" в лучшем случае. В данном же пункте речь идёт об автоматическом исправлении ввода путём эвристического анализа. Например функция должна открывать поток на чтение pdf файла. Пользователь случайно вводит somefile.pfd. В функции происходит исключение потому что такого файла нету, однако эвристический анализ говорит что имя верное, буквы только изменены. Логируется тот факт что система принимает решение за пользователя (нужно для дальнейшего разбирательства - а вдруг пользователь действительно хотел открыть файл somefile.pfd), и рекурсивно вызывается функция с другим именем файла.

Что же можно сказать о гипотетических результатах применения данного подхода.
1. Сложность программы возрастает существенно
2. Скорость работы в штатном режиме не изменяется. При исключительной ситуации зависит от конкретного случая и реализации
3. Размер программы увеличивается.
4. Отказоустойчивость увеличивается очень сильно (при практическом повсеместном использовании вышеперечисленных принципов) - фактически единственным способом заставить программу не работать - убить через taskmanager.