такой подход приведет к тому что код в начале потока будет в 80% случаев получать исключение неизвестно по какой причине и как возник�?ее, например стэк трэйс на вэб странице, ни один из модулей который будет использовать такой метод и понятия не будет иметь о том что гдето в глубине ктото выбросил анчекед исключение и результат его может быть самым удручающим,
например: если такой метод кто-то начнет использовать в цикле то из-за одноко неправильного объекта переданого в метод, который выкинет анчекед из-за нару�?ения контракта, вместо скажем ожидаемого списка из нескольких строк на экране клиент не увидит ни одного, а мог бы просто увидеть на один мень�?е (тот который послужил причиной исключения) А произойдет это потому что девелопер который будет писать вывод понятия не будет иметь что данный конкретный метод
может просто выкинуть тот или иной рантайм, если такой метод в случае нару�?ения контракта выбросит чекед исключение то пользователь метода будет иметь информацию и ре�?ит что ему делать с данным исключением, код будет иметь более предсказуемое поведение а следственно станет более професиональным.

�?спользование анчекед исключений где попало как раз и делает код мало пригодным к использованию, поскольку как раз скрывает тот самый контракт метода, когда пользователь метода понятия не имеет какие исключения могут вылететь из данного метода. А вылетать такие исключения как раз любят на продак�?ене во время демонстрации системы заказчику.

Статья кстати выглядит немного поверхностной, основная проблема в написании комерческого софта именно в том чтобы сделать его реюзабельным и легко изменяемым к постоянно меняющимся требованиям при этом надежным, предсказуемым и устойчивым. Поэтому приведенная цитата о том что 90% кода обрабатывает исключения а 10% делает работу - это цитата человека который врядли писал что-то что потом используют другие… поскольку работа програмы включает в себя и надежность и предсказуемость и повторяемость результатов и мас�?табируемость и возможность использовать код еще кем-то, все то что отличает комерческий код профи от кода студента.

public boolean foo (int a) {
if (_bablo >= a){
bablo-=a;
return true;
}
return false;
}

�?справленный пример кода - http://paste.bradleygill.com/index.php?paste_id=185

смотрите:

class Banka {
private double _bablo;
public double getBablo (){return _bablo;}
public void foo (int a) {
if (_bablo < a)
b.foo (_bablo);
else
_bablo -= a;
}
}

использование в вариенте 1.
Banka b = new Banka ();
double sum = 0;
double bablo = b.getBablo();
b.foo (100);
if (bablo <= 100)
sum += 100;
else
sum += bablo;

второй вариант:

class Banka {
private double _bablo;
public double getBablo (){return _bablo;}
public void foo (int a) {
if (_bablo < a)
throw new NoBablo();
_bablo -= a;
}
}

использование в вариенте 2.
Banka b = new Banka ();

try{
b.foo (100);
}
catch (NoBablo e){
// no bablo
}

Кажется, что разницы между первым подходом и вторым нет. �? там и там есть контроль над снятием денег. Но в первом случае мы размазываем логику работы банка во множестве мест.
А теперь представим ситуацию, что правило снятия бабла поменялось (хотя на стадии проектирования аналитик клялся, что никогда и нигде такого быть не может, но мы все знаем цену их обещаниям) и теперь можно снимать бабло на сумму боль�?ую чем есть на счете. Соотвественно, правим метод (это легко), а потом по�?ли искать в тысяче мест где возможно мы вставили проверку перед вызовом foo (снятием денег).

Очень дурной стиль так делать.

Хм. это почему? Альтернатива? Я же говорю не об использовании исключений для управление flow программы, а об использовании их для сигнализации того, что запро�?енная операция не может быть выполнена с объяснением причины.

Очень дурной стиль так делать.