Shaggie, хаха! посмеялся +1.  Я еще раз повторюсь - один из вариантов который я предложил, чтоб избежать ошибок - завернул в "Exception", но конечно, скорее всего, лучше было бы получить с помощью сравниния всевозможных ситуаций, и возможно, это правильней и производительней ) Всё равно как ни крути любая программа содежит минимум 3 ошибки. А на счет return в середине блока, даже в книге Шилдта и Нортона, которых стояли у истоков языка, не рекомендовали использовать возврат в середине функции. Да и как по мне, сложнее читать чужой код когда ищешь где функция должна вернуть тебе ответ, согласитесь гораздо проще увидеть что на входе(вызов функции) и что на выходе(возврат - return).

Шилдт и Нортон попсовики-писатели, им все равно про что боянить Java, C++, .Net

В книге Джоша Блоха "Effective Java" в главе посвящённой equals он как раз не гнушается использовать возвраты точь в точь как chief39. А ведь товарищ - архитектор Java, его фамилию можно наблюдать в исходных кодах.

Каждому своё.

Что значит попсовики-писатели??

Добавлено через 4 минуты и 40 секунд
Shaggie, конечно - это то же что и обсуждать стиль написания программы. каждому своё, но есть стандарты.

Добавлено через 11 минут и 42 секунды
Shaggie, Книгу конечно полистаю "Effective Java: Programming Language Guide
 By Joshua Bloch"

Shaggie, где можно взять русский перевод?

Как пишет Мартин Фаулер (и я с ним полностью согласен на основе своего опыта) идея одной точки выхода (избегание возвратов в разных местах функции) - очень эффективна в рамках концепции структурного программирования. Однако, java это уже ООП, в котором размер методов как правило невелик, и обычно гораздо проще понимать код, когда выход из функции происходит именно в тот момент (в той точке), когда становится ясно, что дальнейшая его работа уже не нужна. Потому лично я сторонник стиля, о котором пишет chief39

Обычно методы(не функции! это важно в данном контексте) по сути и не требуют десяти ретурнов. Но требют по логике работы парочки throw. Т.к. могут быть неопределённости в процессе выполнения.
А супербольшие методы - это уже зло.

А вот методы, подобные иквалз и хэшкод - довольно специфичны по задаче своей.
Большинство методов работают с какими-то осмысленными крупнозернистыми операциями.
А такие сервис-методы имеют задачей "проверить все поля и сказать ДА или НЕТ".
Упомянутые недавно КА этим и занимаются. И лучше оптимизировать, дабы не танцевать вокруг всего объекта, если по первому пропери уже ясно что ОБЪЕКТ НЕ КАНАЕТ.
Джавасоздатели зачем-то сделали короткое замыкание в логических выражениях  Неужто в этом тоже нет смысла?   

По логике А:
"тэк, взяли объект, ага.. он налл - всё, до свиданья! Не налл? Аха.. проверяем дальше, что там в следующем проперти? ...."
По логике В:
"взяли. попробовали. налл. эксепшн. так. теперь пошли ловить эксепшн. ага, поймали, выходим."
Или ещё лучше:
"ага, налл.. запишем в переменную метода. так, пошли дальше, дальше, дальше, дальше... ага. конец. тааак... что там с переменной? ага.. не подошло ещё в саомм начале... тэээк-с.. начинаем выходить из метода".
Красиво, кто ж спорит   

Имхо, дискуссия на тему throw/if-return не имеет смысла. Оба имеют свои пределы применения, обоими можно злоупотреблять. Не будете же вы все if заменять на throw. И наоборот. Так чего спорить-то? 
Предпочитаете кидать эксепшены - кидайте. Если переборщите, сами услышите "запах" кода.   
То же самое и в обратном направлении.

Вот правильно реализованный метод equals()

Во-первых, метод equals() не должен породить NullPointerException, если аргумент == null. Читаем javadoc:

Во-вторых, если вы используете instanceof вместо однозначной идентификации класса, вам стоит сделать метод equals() финальным. Потому что в ином случае наследник вашего класса может нарушить одно важное правило:

В инете - не знаю, а в книжном видел за 280 р., попробуй поискать. Чуть не купил... денег с собой не было. Красноярск.

Причем сами создатели JDK нарушают это правило 

Добавлено через 4 минуты и 14 секунд
Хотя по мне, реализация через getClass() не самая лучшая.