Только это и остаётся. Но это замусоривает код. Возвращаясь к примеру с UnsupportedCharacterEncoding, можно отметить, что если нужно написать метод, который занимает 5 строчек, а теперь приходится к нему добавить еще 5 строк try-catch-rethrow RuntimeException, то это же чистый мусор.
Согласен, но с восьмой версией и возможностью ловить несколько исключений проблема, на мой взгляд стала менее острой. Для меня плюсы от их использования, перевешивают необходимость написания 3-х строк кода. А вообще соглашусь с тем что UnsupportedChacacterEncoding — хороший пример плохого использования checked exceptions.
Ну и конечно же, наличие checked исключений и легкость избавления от них пустым catch-блоком побуждает начинающих делать это в больших количествах.
Бейте по рукам! :)
Мне кажется, что по пустому catch блоку ошибку понять легче, нежели по не обернутому методу.
Про пункт с не очень опытным программистом. Эта проблема решаема статическим анализатором (и в IDE?), который бы говорил «чувак, возможно ты пропустил исключение здесь!».
Статический анализатор будет работать либо только со стандартной библиотекой, что не решает всех проблем, либо опираться на документацию конкретного функционала, что тоже не всегда надежно работает :(
Сегодня уже любой согласится, что проверяемые исключения были плохой идеей.
Ой, да ладно. Насколько я знаю, основная претензия к checked исключениям, состоит в том многие на них забивают просто оставляют пустой catch блок. При этом нормальных альтернатив не очень предлагается.
К примеру:
public FileInputStream(File file) throws FileNotFoundException {...} // FileNotFoundException - checked
явно заставляет программиста при использовании этого конструктора, включать мозг и что-то делать с возможностью того что данный файл будет не найден. Если это будет пустой catch блок — это тоже решение, но это решение программиста который пишет код, которое он (я надеюсь) обдумал.
Если бы в данном случае кидался unchecked то возможно было бы 2 печальных сценария:
не очень опытный программист — забыл бы обработать это сценарий и узнал бы о нем потом, когда было бы уже поздно
опытный программист — полез бы в документацию смотреть какое исключение там кидается в случае если что-то пошло не так
Если вы не любите checked exception никто не мешает заворачивать их вызовы в try/catch и пробрасывать дальше как unchecked. Тем более что если у Вас решено их не использовать то их вызовы будут использоваться только при работе с внешним API.
да, вы правильно поняли. Проблема в том что мы либо пишем один универсальный «шейдер для всего», но тогда в нашем случае текстура dUdV не будет делать ничего в 90% случаев (для объектов отличных от планет), либо пишем отдельный «шейдер для планет», который рисуем только планеты
Подскажите, а насколько подход 1-2-несколько шейдеров для ОДНОГО ТИПА объектов оправдан, по вашему мнению?
Да это дает нам возможность делать крутые визуальные штуки только за счет написания кода, без художников (ура!). Но ведь в дополнение мы получаем необходимость поддерживать\оптимизировать прорву шейдерного кода, который с одной стороны индивидуален для каждого типа объектов (для планет — один набор шейдеров, для кораблей другой, для космических мух — третий), с другой стороны многие куски кода будут повторяться (к прим. расчет освещенности от звезд). Также, переключение между шейдерами при отрисовке не очень дешевая операция, поэтому есть риски и по производительности.
Если машина приехала совсем грязной, можно просто позвонить и попросить другую. В общественном транспорте, насколько я знаю, не проверяют состояние сидений после каждого пассажира. Зато представьте каким шиком будет заехать за девушкой на машине с живым водителем :)
1) Есть ли принципиальная разница между CV и резюме или это одно и то же?
2) Стоит ли пытаться уместить резюме на одной странице? Где-то слышал что в США\Канаде это является своеобразным стандартом при написании резюме.
3) Если опыт достаточно большой стоит ли указывать все компании или можно опустить вещи относящиеся к началу карьеры?
Проблема с diamond square состоит в том, что «из коробки» он не очень подходит для генерации бесконечных ландшафтов. В тоже время, в случае шумов Перлина, мы сразу получаем возможность генерировать карты высот любого размера и разрешения, а если использовать более чем одну октаву то можно добиться вполне неплохих результатов, к примеру вот ландшафт сгенерированный с помощью 8-и октав:
Вообще если есть желание сделать очень-очень реалистичные горы — советую обратить внимание на алгоритм Diffuse Limited Aggregation, который правда обладает тем же недостатком (плохо подходит для генерации бесконечного ландшафта).
Идея хорошая, но она не позволяет полностью решить проблему обработки массового скопления игроков. Проблема в том, что если мы снизим скорость игры в 10 раз (как в нашем примере), то это линейно отразится на скорость обработки запросов сервером (в идеальном мире — производительность увеличиться в 10 раз). В то же время передача информации о близлежащих объектах (а также в большинстве случаев — обработка их взаимодействия) это задача с квадратичной сложностью (N игрокам нужно сообщать об N игроках).
Второй этаж, сторона с дверью, ближний к окну шкаф, пятая полка сверху (на которой книги в два ряда стоят), неподалеку от стопки красных книг — вроде как том Пушкина (инициалы четко видны, а вот дальше с трудом различимо)
Согласен, но с восьмой версией и возможностью ловить несколько исключений проблема, на мой взгляд стала менее острой. Для меня плюсы от их использования, перевешивают необходимость написания 3-х строк кода. А вообще соглашусь с тем что UnsupportedChacacterEncoding — хороший пример плохого использования checked exceptions.
Бейте по рукам! :)
Мне кажется, что по пустому catch блоку ошибку понять легче, нежели по не обернутому методу.
Статический анализатор будет работать либо только со стандартной библиотекой, что не решает всех проблем, либо опираться на документацию конкретного функционала, что тоже не всегда надежно работает :(
Ой, да ладно. Насколько я знаю, основная претензия к checked исключениям, состоит в том многие на них забивают просто оставляют пустой catch блок. При этом нормальных альтернатив не очень предлагается.
К примеру:
явно заставляет программиста при использовании этого конструктора, включать мозг и что-то делать с возможностью того что данный файл будет не найден. Если это будет пустой catch блок — это тоже решение, но это решение программиста который пишет код, которое он (я надеюсь) обдумал.
Если бы в данном случае кидался unchecked то возможно было бы 2 печальных сценария:
Если вы не любите checked exception никто не мешает заворачивать их вызовы в try/catch и пробрасывать дальше как unchecked. Тем более что если у Вас решено их не использовать то их вызовы будут использоваться только при работе с внешним API.
На StackOverflow есть хороший пост с обсуждением
Подскажите, а насколько подход 1-2-несколько шейдеров для ОДНОГО ТИПА объектов оправдан, по вашему мнению?
Да это дает нам возможность делать крутые визуальные штуки только за счет написания кода, без художников (ура!). Но ведь в дополнение мы получаем необходимость поддерживать\оптимизировать прорву шейдерного кода, который с одной стороны индивидуален для каждого типа объектов (для планет — один набор шейдеров, для кораблей другой, для космических мух — третий), с другой стороны многие куски кода будут повторяться (к прим. расчет освещенности от звезд). Также, переключение между шейдерами при отрисовке не очень дешевая операция, поэтому есть риски и по производительности.
1) Есть ли принципиальная разница между CV и резюме или это одно и то же?
2) Стоит ли пытаться уместить резюме на одной странице? Где-то слышал что в США\Канаде это является своеобразным стандартом при написании резюме.
3) Если опыт достаточно большой стоит ли указывать все компании или можно опустить вещи относящиеся к началу карьеры?
Вообще если есть желание сделать очень-очень реалистичные горы — советую обратить внимание на алгоритм Diffuse Limited Aggregation, который правда обладает тем же недостатком (плохо подходит для генерации бесконечного ландшафта).