Насчет наследования от RuntimeException.
Если у вас есть единая точка обработки какого-то вашего исключения, будет очень утомительно во всех методах ваших классов прописывать выкидывание этого исключения.
А если возможных исключений порядка 5 (что бывает намного чаще, чем хотелось бы)? Все прописывать в сигнатуры методов? Это был бы громадный шаг к потере читаемости.
Если бы все исключения были бы проверяемыми, Вам пришлось бы проверять во всем коде NPE, деление на ноль, передачу неверных параметров и т.д., даже там, где заведомо известно, что этого не может быть.
Checked exceptions в JVM используются для того, чтобы сигнализировать об ошибках, возникновение которых мы не можем контролировать. В частности, ошибки ввода/вывода. И это не панацея.
Есть один вариант, когда стоит предпочесть исключения, а не коды ошибок.
Это случай возврата из нескольких вложенных функций. В этом случае протягивать коды ошибок намного более громоздко и шатко, нежели использование исключений.
Много кода.
Мне лично хватило одного упоминания связки состояний компонентов с состояниями конечного автомата, дальше реализация практически очевидна.
P.S. Также хотелось бы заметить, что диалог удобно закрыть интерфейсом для вызывающего кода, в итоге вызывающий код вообще отвязан от диалога. Что правильно.
Хотите что-то? А в ТЗ нету, ТЗ подписано, т.е. мы вам этого не должны.
Раз хотите — за отдельную плату. Юридический договор в таких делах — отличный аргумент, его все понимают.
Я еще могу с Вами согласиться, когда ошибки пишут прямо в комментах.
А если в личку — IMHO, это нормально.
И если будет специальная кнопка, по которой на статью будут постить ошибки, и никто кроме автора эти ошибки не будет видеть — это, по-моему, очень хороший способ сделать статью лучше. Подчеркиваю — не грамотность автора, а статью.
Если в заброшенном доме разбить хотя бы одно окно, через некоторое время будут разбиты еще несколько окон. Кстати, даже исследование на эту тему проводили.
Я лично считаю, что делать хабр безграмотным через наше бездействие — это не самый правильный подход. Может, лучше будем учить-таки русский язык?
Если данные из базы — используйте SQL, однозначно.
Он как раз предназначен для выборок.
Если же данные из внешнего источника (не БД), то используйте hash set для списка детей и обход всех детей (предлагается использовать итератор — абстрагируемся от структуры хранения).
Насчет обоих родителей. В задаче необходимо уточнить, как идентифицируются дети.
Если у вас есть единая точка обработки какого-то вашего исключения, будет очень утомительно во всех методах ваших классов прописывать выкидывание этого исключения.
А если возможных исключений порядка 5 (что бывает намного чаще, чем хотелось бы)? Все прописывать в сигнатуры методов? Это был бы громадный шаг к потере читаемости.
Checked exceptions в JVM используются для того, чтобы сигнализировать об ошибках, возникновение которых мы не можем контролировать. В частности, ошибки ввода/вывода. И это не панацея.
Это случай возврата из нескольких вложенных функций. В этом случае протягивать коды ошибок намного более громоздко и шатко, нежели использование исключений.
Скажите, Вы действительно сталкивались со всеми, описанными Вами проблемами?
Мне лично хватило одного упоминания связки состояний компонентов с состояниями конечного автомата, дальше реализация практически очевидна.
P.S. Также хотелось бы заметить, что диалог удобно закрыть интерфейсом для вызывающего кода, в итоге вызывающий код вообще отвязан от диалога. Что правильно.
Раз хотите — за отдельную плату. Юридический договор в таких делах — отличный аргумент, его все понимают.
А у Вас наоборот — заканчивается вопросом. Ладно бы он еще был риторическим…
Хотя это уже вопрос психологии.
А если в личку — IMHO, это нормально.
И если будет специальная кнопка, по которой на статью будут постить ошибки, и никто кроме автора эти ошибки не будет видеть — это, по-моему, очень хороший способ сделать статью лучше. Подчеркиваю — не грамотность автора, а статью.
Это ж сообщество, все-таки. Куда ж тут без юмора :-)
Я лично считаю, что делать хабр безграмотным через наше бездействие — это не самый правильный подход. Может, лучше будем учить-таки русский язык?
Или Вам лень?
Вы, что ли, этим займетесь?
P.S. И меню «Пуск» справа.
Тут обратный процесс, дедуктивный.
Все это можно реализовать и с использованием процедурного подхода, но в ООП оно ложится естественным образом.
Он как раз предназначен для выборок.
Если же данные из внешнего источника (не БД), то используйте hash set для списка детей и обход всех детей (предлагается использовать итератор — абстрагируемся от структуры хранения).
Насчет обоих родителей. В задаче необходимо уточнить, как идентифицируются дети.