Если вы в курсе, то поясните насколько целочисленное (не с плавающей точкой) умножение выполняется быстрее деления.
На практике проверил несколько тестов — разницы не выявил.
В сети нашел данные: IDIV выполняется за время от от14 до 41 тактов, IMUL за время от от 9 до 41. Но это данные для Intel 80386. Но для этого процессора еще был математический сопроцессор (отдельно).
Интересуют не предрассудки, основаные на временах Intel 80386, а реальное положение дел.
checked сделаны как раз для человека — именно из за нашей проблемы с внимательностью. Если исключения тупо перечислить в документации — мы можем пропустить несколько и одна из ветвей исполнения будет неверно обработана.
Если бы мы обладали 100% вниманием — этого не потребовалось бы.
Что бы вы предложили изменить или улучшить в этой концепции?
Могу, но нахе зачем? Без checked exceptions вообще ничего такого не надо делать.
Чтобы не забыть предусмотреть все исключительные случаи.
Без checked вы отложите это решение на потом.
К примеру, если возникло FileNotFoundException, вы можете предложить пользователю создать файл (или создать за него без вопросов — зависит от вашей бизнес-логики). Ведь не обязательно в этом случае сразу закрывать программу с записью в лог…
Каждое нужно обработать по-особому. Но вам не охота городить километровые списки throws, поэтому вы наследуете из от А0 и объявляете в методе только его.
Если нужно обработать по особому, значит нужно все случаи прописать, не лениться.
Здесь кодировка захардкожена и работа этого метода проверена прямо сразу после его написания. Поскольку параметр не меняется, то и исключения этого никогда не будет.
Работу с кодировками, криптографию и пр. я называю слоем утилит.
Слой утилит вводит свои спец. исключения, к примеру UnsupportedEncodingException или WrongKeyException.
Естественно, если у входящие данные для слоя утилит являются константой — такие исключения не возникнут. Однако это вы знаете уже уровнем выше — из слоя, который вызывает слой утилит.
И именно на данном уровне вы принимаете решение что делать с исключениями слоя утилит (которые ожидаемо могут возникнуть с точки зрения слоя утилит). В вашем случае либо погасить (пустой блок catch) либо обернуть в RuntimeException. Я бы обернул в RuntimeException, т.к. в дальнейшем код может измениться и кодировка уже не будет константой — не сможете быстро понять где возникает проблема.
о это всё равно не отменяет того, что в некоторых случаях это исключение либо будет фатальным, либо не будет вообще. Следовательно, и оно тоже не дложно быть checked.
Однако разработчик DataInputStream такого решения принять не может. Он не знает какой именно поток будут передавать.
Зато такое решение сможете сделать вы на своем уровне абстракции. В некоторых случаях вы обернете в RuntimeException, в других же случаях превратите в бизнес-исключение.
Идея проверяемых исключений верная, только большинство людей ее не поняли и не умеют их готовить.
Но что получается, когда проверяемое исключение обрабатывается на много уровней выше? Его придется добавить в сигнатуры многих методов. И чем больше их появляется, тем «веселее». Не так уж удобно, но, может быть, это необходимое зло?
Если для метода данное исключение не является основным бизнес-правилом (от чего зависит логика выполнения уровнем выше), то оборачиваете его либо в RuntimeException либо в новое бизнес-исключение.
В этом и заключается главный секрет по использованию проверяемых исключений. Осознав это правило, использовать проверяемые исключения легко и приятно.
Для нас FileNotFoundException такая же фатальная ошибка, как какой-нибудь NPE, но мы вынуждены объявить его в десятках мест выше только для того, чтобы где-то на самом верху поймать и залогировать:
В вашей бизнес-логике FileNotFoundException теряет свою ожидаемость. Вот в том месте, когда он теряет свою ожидаемость, делаете такой финт:
throw new RuntimeException(fileNotFoundException);
Все! И теперь все сигнатуры верхних методов не содержат бессмысленного для них FileNotFoundException.
наследуют все свои проверяемые исключения от одного предка — ApplicationNameException. Теперь они обязаны ловить в обработчике еще и его (checked же!):
А почему бы не отловить базовый тип исключения в самом первом блоке catch, если у всех обработка аналогичная? Главное чтобы блок с базовым был раньше дочерних.
Вот так и получается: либо километровый список throws, либо потеря гарантии проверяемости. Оно вам надо?
В вашем случае нужно добавить еще один уровень иерархии. Т.е. базовый класс, n подклассов с разным типом обработки, от каждого из подклассов наследуем десятки классов, которые обрабатывем одинаково.
Если нужна спец. обработка — вводим еще одного наследника базового класса. Не нужна — значит наследника, для которой уже есть обработка и наследуемся от него.
Надоели длинные списки throws? Бросай везде просто Exception! Компилятор схавает:
Хм. Согласно таблице из Wiki, ДНК человека и шимпанзе совпадает на 98,7 %. А человека и другого человека на 99,9 %.
Если я правильно понял, погрешность в 1% не увидит разницы даже между человеком и обезьяной, не говоря уже об отличии человека от другого человека. Т.е. в ракурсе такой погрешности все люди будут совершенно одинаковыми.
У меня главный вопрос: как практически это уже можно использовать? Каковы перспективы использования?
И, простите, может не так понял:
Более того, это может означать, что множество объектов и источников в природе мы просто не видим, потому что они не взаимодействуют с электромагнитными полями, а взаимодействуют исключительно с потенциалами!
Это о чем? О темной материи? Или о гипотетических объектах, которые в теории могли бы существовать, но существуют ли они — х.з.?
Автор с задачей не справился — статья не в научно популярном стиле. Нужно было написать так, чтобы у среднего человека вопросов не возникло. Хотя, в данном случае, видимо, это очень сложная задача.
Стартаперы мечтают немного поднапрячься, в обмен на то, что плюшек и свободы получат больше чем офисные работники. Ключевое слово «немного». Т.е. в жестком режиме работы по 12 часов в сутки могут проработать ну пусть 2-3 месяца.
А инвестор, как наивный чукотский юноша, ожадает что стартаперы будут за его деньги «опу рвать» постоянно.
В итоге имеем конфликт интересов. Когда стартаперы, наконец, получили живые деньги — они вздыхают с облегчением и щедро награждают себя за минувшие дни тяжкой работы. В ленте фейсбука появляются улыбающиеся люди на квадрациклах, в ресторанах и пр., что изрядно коробит инвестора (ведь деньги он давал не для их счастья, а для продолжения тажкой работы, чтобы самому поиметь с них денег).
Здесь нужен здравый баланс.
Стартаперы, конечно, не должны прекращать работы. Но ожидать от них прежней отдачи не стоит. Инвестору нужно смириться с лентой фейсбука, ведь в первую очередь мы все люди и хотим счастья и наслаждений (вы ведь все это уже получили ранее).
Вот что делают три из четырех стартапов сразу же после получения первоначальных инвестиций:
Интересно посмотреть на те 25%, которые этого не делают… И главный вопрос — почему не делают? Деньги любят больше чем свою жинь, или же у них все это уже было и является пройденным этапом?
На счет 1 такта, действительно ошибся.
Точных данных для современных процессоров не нашел. Для 80386 от 14 до 41, и от 9 до 41 тактов на деление и умножение соответственно.
Думаю что разница если и есть, то на тестах она будет практически не заметна (для целых чисел).
По этому нужно делать выбор в пользу более понятного кода.
На практике проверил несколько тестов — разницы не выявил.
В сети нашел данные: IDIV выполняется за время от от14 до 41 тактов, IMUL за время от от 9 до 41. Но это данные для Intel 80386. Но для этого процессора еще был математический сопроцессор (отдельно).
Интересуют не предрассудки, основаные на временах Intel 80386, а реальное положение дел.
Для целых чисел разве есть разница в скорости? Ведь и та и другая команда процессора выполняется за 1 такт.
Сначала мы заменим компьютером чиновников и управленцев.
Если бы мы обладали 100% вниманием — этого не потребовалось бы.
Что бы вы предложили изменить или улучшить в этой концепции?
Чтобы не забыть предусмотреть все исключительные случаи.
Без checked вы отложите это решение на потом.
К примеру, если возникло FileNotFoundException, вы можете предложить пользователю создать файл (или создать за него без вопросов — зависит от вашей бизнес-логики). Ведь не обязательно в этом случае сразу закрывать программу с записью в лог…
Если нужно обработать по особому, значит нужно все случаи прописать, не лениться.
Работу с кодировками, криптографию и пр. я называю слоем утилит.
Слой утилит вводит свои спец. исключения, к примеру UnsupportedEncodingException или WrongKeyException.
Естественно, если у входящие данные для слоя утилит являются константой — такие исключения не возникнут. Однако это вы знаете уже уровнем выше — из слоя, который вызывает слой утилит.
И именно на данном уровне вы принимаете решение что делать с исключениями слоя утилит (которые ожидаемо могут возникнуть с точки зрения слоя утилит). В вашем случае либо погасить (пустой блок catch) либо обернуть в RuntimeException. Я бы обернул в RuntimeException, т.к. в дальнейшем код может измениться и кодировка уже не будет константой — не сможете быстро понять где возникает проблема.
Однако разработчик DataInputStream такого решения принять не может. Он не знает какой именно поток будут передавать.
Зато такое решение сможете сделать вы на своем уровне абстракции. В некоторых случаях вы обернете в RuntimeException, в других же случаях превратите в бизнес-исключение.
Если для метода данное исключение не является основным бизнес-правилом (от чего зависит логика выполнения уровнем выше), то оборачиваете его либо в RuntimeException либо в новое бизнес-исключение.
В этом и заключается главный секрет по использованию проверяемых исключений. Осознав это правило, использовать проверяемые исключения легко и приятно.
В вашей бизнес-логике FileNotFoundException теряет свою ожидаемость. Вот в том месте, когда он теряет свою ожидаемость, делаете такой финт:
throw new RuntimeException(fileNotFoundException);
Все! И теперь все сигнатуры верхних методов не содержат бессмысленного для них FileNotFoundException.
А почему бы не отловить базовый тип исключения в самом первом блоке catch, если у всех обработка аналогичная? Главное чтобы блок с базовым был раньше дочерних.
В вашем случае нужно добавить еще один уровень иерархии. Т.е. базовый класс, n подклассов с разным типом обработки, от каждого из подклассов наследуем десятки классов, которые обрабатывем одинаково.
Если нужна спец. обработка — вводим еще одного наследника базового класса. Не нужна — значит наследника, для которой уже есть обработка и наследуемся от него.
Это и прочее от неумения их готовить.
Есть мнение что научить думать можно только до 5 лет. И то не каждого.
А основная заслуга МатМеха — отобрать тех, кто думать уже умеет. Дурак туда если и попадет (за деньги, к примеру), то один хрен думать не научится.
На их видео лазер подпаливает волос очень медленно. Если так — то не удобно будет бриться.
За 10 лет обучения = 200 тыс.
Это же вся человеческая жизнь среднего человека, выраженная в денежном эквиваленте.
Хм. Согласно таблице из Wiki, ДНК человека и шимпанзе совпадает на 98,7 %. А человека и другого человека на 99,9 %.
Если я правильно понял, погрешность в 1% не увидит разницы даже между человеком и обезьяной, не говоря уже об отличии человека от другого человека. Т.е. в ракурсе такой погрешности все люди будут совершенно одинаковыми.
И, простите, может не так понял:
Это о чем? О темной материи? Или о гипотетических объектах, которые в теории могли бы существовать, но существуют ли они — х.з.?
Автор с задачей не справился — статья не в научно популярном стиле. Нужно было написать так, чтобы у среднего человека вопросов не возникло. Хотя, в данном случае, видимо, это очень сложная задача.
Стартаперы мечтают немного поднапрячься, в обмен на то, что плюшек и свободы получат больше чем офисные работники. Ключевое слово «немного». Т.е. в жестком режиме работы по 12 часов в сутки могут проработать ну пусть 2-3 месяца.
А инвестор, как наивный чукотский юноша, ожадает что стартаперы будут за его деньги «опу рвать» постоянно.
В итоге имеем конфликт интересов. Когда стартаперы, наконец, получили живые деньги — они вздыхают с облегчением и щедро награждают себя за минувшие дни тяжкой работы. В ленте фейсбука появляются улыбающиеся люди на квадрациклах, в ресторанах и пр., что изрядно коробит инвестора (ведь деньги он давал не для их счастья, а для продолжения тажкой работы, чтобы самому поиметь с них денег).
Здесь нужен здравый баланс.
Стартаперы, конечно, не должны прекращать работы. Но ожидать от них прежней отдачи не стоит. Инвестору нужно смириться с лентой фейсбука, ведь в первую очередь мы все люди и хотим счастья и наслаждений (вы ведь все это уже получили ранее).
Интересно посмотреть на те 25%, которые этого не делают… И главный вопрос — почему не делают? Деньги любят больше чем свою жинь, или же у них все это уже было и является пройденным этапом?