Решать проблемы и копаться в чужом коде это все-таки немного разные уровни вопроса. Скилл решать проблемы мы проверяем усложняя кандидату задачу до предела его способностей. В простейшую задачу вычисления Фибоначчи можно поднакидать real-life issues столько, что никто не сможет решить все и одновременно — отличная возможность посмотреть, как человек умеет простраивать технические компромиссы.
А копаться в чужом коде — это конкретная область применения навыка решения проблем. Как я уже писал, мое мнение, что это вопрос больше мотивации — человек просто не ощущает достаточной мотивации чинить чужой код, потому что не видит, как это связано с его собственными персональными целями.
Это я прежде всего по своему собственному опыту говорю — я считаю себя довольно неплохим problem solver-ом, но я несколько раз сталкивался с ситуацией, когда мозг просто отказывается даже начинать решать задачу «как починить этот адовый пи#$ец». Это происходит тогда, когда, по моей личной интуитивной оценке (которая, конечно, может не совпадать с оценкой руководства проекта) починка этой конкретной проблемы просто пустая трата времени, потому что ситуация в целом настолько поганая, что ложка меда только ухудшит общий вкус бочки дегтя.
Мне кажется, если человек показал себя умеющим думать, но не может разобраться в незнакомом коде/среде/продукте — это вопрос мотивации а не способностей. Человек не хочет этим заниматься, вот и все. Вопросы мотивации — это вопросы project screening-а больше, хотя, конечно, мы на tech-screening стараемся примерно обрисовать кандидату возможные области работы.
Если вы ходите по собеседованиям просто потому что «позвали» — то это и есть ваш честный ответ на такой вопрос. Если же вам кажется, что это не тот ответ, который добавит вам плюсов в глазах собеседующих — возможно, это и так, а возможно и нет — все зависит от того, кого люди ищут.
Мое личное мнение — специалист действительно высокого уровня знает, где он хочет специализироваться, и сам выбирает, куда ему идти пробоваться. И не по принципу «какие компании на слуху», а по принципу «чем я действительно хочу заниматься, и где этим занимаются». И у такого специалиста найдется ответ на этот вопрос.
Нет ничего плохого в том, что вы ищете работу просто по критерию «где я буду продавать свое время за деньги». Но и больших плюсов в глазах работодателя в этом тоже нет (как правило). Действительно сложную работу невозможно делать хорошо только за зарплату — нужно, чтобы у человека была какая-то внутренняя мотивация эту работу делать. Поэтому на сложную задачу предпочтут взять пассионария, ясно понимающего зачем для самого себя он это хочет делать — нежели карьериста.
Вы знаете, на раннем этапе своей карьеры мне тоже этот вопрос казался глупо-пафосным — потому что я ходил на те собеседования, на которые звали.
Сейчас он мне уже не кажется глупым — потому что я реже хожу «куда позвали», и чаще туда, где я бы хотел работать — т.е, как минимум, у меня есть какие-то причины предполагать, что я хотел бы работать именно здесь. И я с удовольствием расскажу людям об этих причинах, и послушаю, что они мне скажут в ответ на мои фантазии.
Ну вот в где-то в Нидерландах, по слухам, бабло капает от свободной продажи наркотиков и легальной проституции — про порнорграфию я скромно умолчу. Жалкая, бескультурная, темная страна. Все ездят на велосипедах — наверное, просто разучились делать машины.
Разве культура падает от наличия наркотиков и порноргафии? Вы еще скажите, что культура падает от того, что в стране появляется секс и люди начинают видеть сны. Наоборот — потребность в наркотиках и порнографии является симптомом того, что у людей нет возможности реализовать себя в реальной жизни.
Точно так же и со стихами — разве проблема в том, что есть плохие стихи? Да побойтесь бога, плохие стихи всегда были, и их всегда было гораздо больше, чем хороших. Вам кажется, что люди стали предпочитать плохие стихи хорошим? Я сомневаюсь, что когда либо было иначе — если смотреть на общество в целом, а не на редкую прослойку элиты, от жизни которой осталось больше материальных свидетельств. Но даже если предположить, что сейчас почему-то действительно плохие стихи люди стали любить больше хороших — может быть, важнее задуматься почему так происходит? Может быть это происходит потому, что реальная жизнь этих людей гораздо больше похожа на плохие стихи, чем на хорошие? И может быть тогда эти плохие стихи стоит считать хорошими — если уж именно они действительно резонируют в сердцах людей?
Что касается мыльных опер — на мой взгляд очень показательно то, что в США, где в середине 20-го века плодились мыльные оперы, сейчас снимают гораздо более качественные сериалы. И безо всякого государственного регулирования, насколько мне известно. Возможно, люди просто наелись мыла? Возможно, культура способна саморегулироваться и без указаний из Министерства Хранителей Истинной Православной Культурной Традиции?
Насчет мудрецов — я все-таки полагаю, что они видели тренды, и интуитивно ощущали смысл, за ними стоящий — а не только фиксировали текущее состояние дел. Какой смысл был бы формулировать «ни убий» если вокруг и так никто не убивает, а?
Мне кажется, что все-таки задачи «что» и «как» должны решаться параллельно. Если вдруг завтра кто-то найдет идеальную цель которая подойдет 99% населения планеты — что вы будете с ней делать, если у вас нет инструментов ее достижения? (Собственно, свобода-равенство-и-братство вас чем-то не устраивают?) Аналогично, если завтра кто-то опубликует Психоисторию — куда именно вы будете ее применять? Без достойной цели это может быть пострашнее атомного оружия.
Но в целом, конечно, понятно, что субъективность присутствует всегда. Просто важно понимать, что если уж мы имеем возможность проверять нашу субъективность — то это надо делать, а не прикрываться тем, что такие святые вещи как моральные нормы и традиции предков выше всякого анализа и верификации.
Я думаю, что отбрасывать именно опыт — глупо. А вот его интерпретация может — и должна — совершенствоваться. Солнце восходило на востоке и заходило на западе даже в древней элладе — только тогда полагали, что это колесница бога солнца несется по небу, а мы полагаем, что это планета земля вертится вокруг огромного термоядерного реактора. Вы полагаете, нам стоило до сих пор думать про колесницу?
Древние мудрецы могли предлагать моральные принципы основываясь на своей интуиции. Остальным предлагалось поверить на слово. Сейчас у нас есть теория игр, и мы можем обосновать рациональность реципрокного альтруизма. И — что более важно — мы можем обосновать границы применимости различных моральных норм. Мне кажется, что это задача, над которой стоит работать.
Я не уверен, что вас правильно понимаю. Разумеется, рост подразумевает изменение. И кризисы подразумевают изменение еще в большей степени. Тем не менее, нынешняя культура унаследовала от культуры прошлого все ее артефакты (те, что дожили, разумеется). И будущая культура, какой бы она не была, унаследует от нынешней все, что нынешняя унаследовала от предшественников, плюс то, что нынешняя создала. В этом смысле культура все-таки растет. Хотя интерпретация, смысл вкладываемый в эти артефакты — он меняется. И новый, широко распространенный, смысл может мне не нравиться, да.
Я вижу развитие культуры примерно по такому же сценарию, как Кун описывал развитие науки в своей «структуре научных революций»: возникновение парадигмы — консолидация сообщества вокруг новой парадигмы, развитие парадигмы — кризис парадигмы, разброд и шатания — возникновение новой парадигмы — ре-интерпретация данных старой парадигмы в рамках новой — консолидация вокруг новой парадигмы — и так далее.
Мне кажется важным, что точно так же, как новая научная теория может быть успешной только если она сможет дать объяснение всем фактам, которые объясняла старая — точно так же и новая культура должна успешно ассимилировать в себя все культурные артефакты, оставшиеся ей в наследство от старой. Мое предположение состоит в том, что только при этом условии новая культура будет успешной, в некотором смысле, «здоровой».
Проблема в том, что «не заставляют задуматься» — это зависит от вашего текущего состояния. В вашем внутреннем мире на этом этапе вашей жизни этот материал ни с чем не резонирует — ок, это не для вас нынешнего. Но кто вам сказал, что это ни у кого не резонирует ни с чем важным? Я помню как в школе еще нам учительница цитировала Бодлера («Падаль») — мне тоже было не понятно, что это за мрак-и-ужас. Сейчас, думаю, я в состоянии понять какой-то из слоев — но читать его по-прежнему неприятно. Но я легко могу понять, что французской литературе в какой-то ее период был нужен такой Бодлер.
Мне кажется, у многих людей (и у вас, как мне кажется, тоже) есть какой-то такой образ, что культура должна развиваться линейно — ввысь. Но это противоестественно — все действительно живое развивается проходя через череду кризисов. Чтобы найти новый смысл, и новое видение — часто просто необходимо, чтобы старое умерло. Как бы красиво и величественно оно не было — особенно если старое очень красиво и величественно — в какой-то момент нужно чтобы оно потерпело поражение. Умерло, сгнило, и разложилось. Нужно чтобы люди, которые будут создавать новую культуру — пережили это как личностный кризис, наблюдали это разложение, и пройдя через это нашли внутри себя то, что будет действительно их культурой.
А то, что говорите вы (и наши просвященые депутаты) — похоже на попытку забальзамировать нового Ильича. Старая культура умирает, и с этим ничего не сделать. Новая — когда сформируется — наверняка переоткроет и впитает в себя значительную часть достижений старой. Никуда не исчезнут ни Достоевский, ни Пушкин, ни Плутарх — но, наверняка, в рамках новой культуры они будут читаться иначе, и пониматься тоже иначе.
Меня смущает то, что ваши утверждения содержат такую часть как «ну это же всем очевидно» — в качестве обоснования. Мне кажется, что это совсем не очевидно. Мне было бы спокойнее, если бы я видел научные исследования по этому вопросу. Мне кажется, что реальная ситуация гораздо, гораздо сложнее чем эти городские мифы «культурный — значит хочет творить». Мне было бы гораздо интереснее исследовать взаимосвязи между различными проявлениями культуры и их отражениями во внутреннем мире человека, чем довольствоваться «раньше было лучше, давайте будем как раньше».
Хорошо, дайте определение «культурной планки» — свободное от субъективности. Желательно в пару к нему — доказательство того, что высокий уровень культурной планки — по этому определению — устойчиво коррелирует с успешностью человека в его самореализации.
Бабло капает — от людей, нет? То есть какой-то части общества нравится, правильно? Эти стихи наносят кому-то вред? Вы готовы обосновать наличие этого вреда, его количественные показатели? Сравнить эти показатели с показателями вреда, скажем, от выхлопных газов, или от навязывания людям христианской морали? Разумеется, все это желательно сделать по стандартам научных доказательств — двойное слепое плацебо-контролируемое, авторитетные и рецензируемые научные журналы, и так далее.
Вы, часом, не путаете наличие внутренних ограничителей с наличием внутренних ограничителей, настроенных так, как кажется правильным вам (или еще кому-то — кроме самого человека?)
Разумеется, в тех случаях, где функциональная парадигма изначально естественна, ее эмуляция методами ООП будет выглядеть более монстроподобно.
У ООПшного подхода есть так плюс как самодокументируемость. Что такое «словарь функций»? — как я могу догадаться, что в данном конкретном случае это «почта»? Только поддерживая консистентные имена переменных? Если в какое-нибудь место ваша «почта» будет передана просто как arg3 — что я смогу понять про ее назначение?
В то время как, скажем, интерфейс SubscriptionTopics говорит мне уже гораздо больше — независимо от того, каким путем он ко мне попал. Я даю имя сущности, которая мне нужна — в то время как вы называете реализацию сущности: в одном месте словарь функций может быть «почтой», в другом — частью конечного автомата — это очень разные сущности, а реализация одна.
Исключения — по определению предназначены для исключительных ситуаций. То есть не fast path точно. Так что если у кого-то использование исключений «пагубно сказалось на производительности», то 99% это не исключения, а отсутствие мозговнедостаточная грамотность у разработчиков пагубно сказалось на производительности.
Если все-таки отвечать на вопрос — и да, и нет. «Честный» выброс исключения действительно недешев — по многим причинам. Но если ваш метод действительно зовется часто, то на стадии агрессивной оптимизации он будет, с хорошей вероятностью, заинлайнен по самые помидоры — так, что в реальном коде и выброс и поимка исключения окажутся в одном фрейме стека, и компилятор сможет их соптимизировать до передачи информации об ошибке в локальной переменной. Тогда это будет почти бесплатно. На хабре была хорошая статья Алексея Шипилева с подробными бенчмарками этой ситуации в разных случаях — поищите, оно того стоит.
Более того, есть методы соптимизировать проброс исключения и в более общих случаях — например, можно переиспользовать единственный синглетонный экземпляр исключения, и перегрузить fillStackTrace() чтобы не дергать нативный код. Мне вспоминается, что была какая-то неплохая библиотека, использовавшая такого рода трюки чтобы потом заложиться на исключения как способ управления control flow (о ужас, да?) — и ничего, нормально даже работало. Но это, конечно, то самое исключение, что подтверждает правило — вообще-то так делать не стоит.
Пока у вас нет веских причин оптимизировать — не надо оптимизировать то, что хорошо написано.
>что и другие процессоры тоже могут иметь более свежие данные у себя в кэш-памяти.
Очень смущающее построение фразы. Другие процессоры не могут иметь «более свежие» данные, чем те, что есть у «владельца» (Owner). Может быть один кэш, содержащий строку в O, а остальные кэши либо вообще ее не содержат, либо содержат в S — и тогда ее содержимое скопировано с того самого кэша, который владелец. Подробнее тут
>Есть стоимость написания, есть стоимость поддержки, есть стоимость ошибок. Идеальный код — это код, который минимизирует их сумму. Всё!
Хорошо, продемонстрируйте мне практическое применение вашего определения. Дано:
assert arg !=null : "..."
//против
checkArgument( arg!=null, "...");
//против вообще отсутствия проверки
Покажите, пожалуйста, стоимость написания в каждом случае, стоимость поддержки в каждом случае, и стоимость ошибки в каждом случае — для какого-то из ваших проектов, по вашему выбору. Так, чтобы можно было сравнить, и посчитать сумму, и сделать обоснованный вывод — какой из стилей считать излишним перфекционизмом, какой — непрофессиональностью, а какой как раз зрелым профессионализмом — для данного конкретного проекта.
Мне вот правда интересно, как вы на практике применяете такие высокоуровневые абстракции, когда речь заходит о таких конкретных низкоуровневых вещах?
>Так я вас и не пытался убедить, что NPE заменять на IAE логично. Я напротив считаю, что так как есть — это нормально.
Я отвечал вам на вопрос, почему (возможно) в classlib сделано — и оставлено — как есть. Я не считаю, что использование NPE это прямо таки «ненормально» — я считаю, что IAE лучше — потому что
а) более явно и прямо выражает намерение программиста (не «встретил нулевой указатель», а «некорректный аргумент»)
б) позволяет явно отличить предусмотренную проверку с выборосом исключения от случайного выброса исключения в результате реального разыменования.
Это не те аргументы, чтобы прямо руку давать на отсечение и горло грызть. Более того, одного аргумента против — что classlib использует NPE — уже достаточно. Но не потому, что авторы classlib как-то принципиально умнее, и не могли ошибаться — а именно потому, что массовое применение само по себе создает стандарт. Это как с DVD vs BlueRay — кто первый заполучил массовую популярность, тот и выиграл, и достоинства и недостатки самой технологии — если они не суперкритичны — отходят на второй план. И уже не важно, что изначальное преимущество популярности могло получиться случайно, или по ошибке, или даже незаконным всепланетным еврейским сговором.
>Знаю, я сам из таких людей.
И у вас, конечно, есть бенчмарки, показывающие существенную деградацию производительности вашего приложения в версии с новыми строками? И дизайн этих бенчмарков, конечно, исключает другие причины деградации при смене JDK — кроме смены .substring()?
>А не нравится этот пример, вот вам другой.
Меня эта ситуация самого дико удивила в свое время — там еще с DataSource была похожая петрушка. Однако, еще раз повторяю — одно дело в одном конкретном интерфейсе (который, в общем-то, больше предназначен реализовываться авторами jdbc-драйверов, а не прикладными программистами) нарушить совместимость. А другое — изменить некий стандарт, который commonly used во всей classlib. И ради чего? — ради чуть-чуть большей согласованности? Я ссылался же (а ниже в комментах приводят даже прямые цитаты) — корифеи джавы вон уже несколько лет назад признали, что проверяемые исключения не стоили свеч. Бонус от перехода на непроверяемые, хоть где-то и спорный — все-таки на порядок более весом, чем от перехода NPE->IAE. Тем не менее же никто не чешется переводить classlib на непроверяемые исключения. Более того, я даже не слышал, чтобы новые части стандартной библиотеки разрабатывались с непроверяемыми — т.е. старый стандарт продолжает быть стандартом, хоть даже его авторы уже в нем разочаровались.
Лично я сначала тоже использовал .checkNotNull() для проверки на null, и checkArgument для остального. Но чем больше я у себя внедрял Preconditions, тем больше мне резали глаз сочетания типа
void myMethod(...){
checkNotNull(arg1, "arg1 can't be null");
checkArgument(!arg1.isEmpty(),"arg1 can't be empty");
}
почему в первом случае NPE, а во втором IAE? Смысл ведь один и тот же — такие аргументы методу не подходят. В конечном счете я решил оставить NPE для сторонних библиотек, а в своем коде фиксировать, что невалидные аргументы это всегда IAE.
У checkNotNull появится преимущество когда заработают @ NotNull — тогда с checkArgument придется расставаться, наверное. Ну или переписать checkNotNull так, чтобы бросал IAE :)
Что для вас «справочные данные», которые помнят только юниоры?
А копаться в чужом коде — это конкретная область применения навыка решения проблем. Как я уже писал, мое мнение, что это вопрос больше мотивации — человек просто не ощущает достаточной мотивации чинить чужой код, потому что не видит, как это связано с его собственными персональными целями.
Это я прежде всего по своему собственному опыту говорю — я считаю себя довольно неплохим problem solver-ом, но я несколько раз сталкивался с ситуацией, когда мозг просто отказывается даже начинать решать задачу «как починить этот адовый пи#$ец». Это происходит тогда, когда, по моей личной интуитивной оценке (которая, конечно, может не совпадать с оценкой руководства проекта) починка этой конкретной проблемы просто пустая трата времени, потому что ситуация в целом настолько поганая, что ложка меда только ухудшит общий вкус бочки дегтя.
Мне кажется, если человек показал себя умеющим думать, но не может разобраться в незнакомом коде/среде/продукте — это вопрос мотивации а не способностей. Человек не хочет этим заниматься, вот и все. Вопросы мотивации — это вопросы project screening-а больше, хотя, конечно, мы на tech-screening стараемся примерно обрисовать кандидату возможные области работы.
Мое личное мнение — специалист действительно высокого уровня знает, где он хочет специализироваться, и сам выбирает, куда ему идти пробоваться. И не по принципу «какие компании на слуху», а по принципу «чем я действительно хочу заниматься, и где этим занимаются». И у такого специалиста найдется ответ на этот вопрос.
Нет ничего плохого в том, что вы ищете работу просто по критерию «где я буду продавать свое время за деньги». Но и больших плюсов в глазах работодателя в этом тоже нет (как правило). Действительно сложную работу невозможно делать хорошо только за зарплату — нужно, чтобы у человека была какая-то внутренняя мотивация эту работу делать. Поэтому на сложную задачу предпочтут взять пассионария, ясно понимающего зачем для самого себя он это хочет делать — нежели карьериста.
Сейчас он мне уже не кажется глупым — потому что я реже хожу «куда позвали», и чаще туда, где я бы хотел работать — т.е, как минимум, у меня есть какие-то причины предполагать, что я хотел бы работать именно здесь. И я с удовольствием расскажу людям об этих причинах, и послушаю, что они мне скажут в ответ на мои фантазии.
Разве культура падает от наличия наркотиков и порноргафии? Вы еще скажите, что культура падает от того, что в стране появляется секс и люди начинают видеть сны. Наоборот — потребность в наркотиках и порнографии является симптомом того, что у людей нет возможности реализовать себя в реальной жизни.
Точно так же и со стихами — разве проблема в том, что есть плохие стихи? Да побойтесь бога, плохие стихи всегда были, и их всегда было гораздо больше, чем хороших. Вам кажется, что люди стали предпочитать плохие стихи хорошим? Я сомневаюсь, что когда либо было иначе — если смотреть на общество в целом, а не на редкую прослойку элиты, от жизни которой осталось больше материальных свидетельств. Но даже если предположить, что сейчас почему-то действительно плохие стихи люди стали любить больше хороших — может быть, важнее задуматься почему так происходит? Может быть это происходит потому, что реальная жизнь этих людей гораздо больше похожа на плохие стихи, чем на хорошие? И может быть тогда эти плохие стихи стоит считать хорошими — если уж именно они действительно резонируют в сердцах людей?
Что касается мыльных опер — на мой взгляд очень показательно то, что в США, где в середине 20-го века плодились мыльные оперы, сейчас снимают гораздо более качественные сериалы. И безо всякого государственного регулирования, насколько мне известно. Возможно, люди просто наелись мыла? Возможно, культура способна саморегулироваться и без указаний из Министерства Хранителей Истинной Православной Культурной Традиции?
Мне кажется, что все-таки задачи «что» и «как» должны решаться параллельно. Если вдруг завтра кто-то найдет идеальную цель которая подойдет 99% населения планеты — что вы будете с ней делать, если у вас нет инструментов ее достижения? (Собственно, свобода-равенство-и-братство вас чем-то не устраивают?) Аналогично, если завтра кто-то опубликует Психоисторию — куда именно вы будете ее применять? Без достойной цели это может быть пострашнее атомного оружия.
Но в целом, конечно, понятно, что субъективность присутствует всегда. Просто важно понимать, что если уж мы имеем возможность проверять нашу субъективность — то это надо делать, а не прикрываться тем, что такие святые вещи как моральные нормы и традиции предков выше всякого анализа и верификации.
Древние мудрецы могли предлагать моральные принципы основываясь на своей интуиции. Остальным предлагалось поверить на слово. Сейчас у нас есть теория игр, и мы можем обосновать рациональность реципрокного альтруизма. И — что более важно — мы можем обосновать границы применимости различных моральных норм. Мне кажется, что это задача, над которой стоит работать.
Я вижу развитие культуры примерно по такому же сценарию, как Кун описывал развитие науки в своей «структуре научных революций»: возникновение парадигмы — консолидация сообщества вокруг новой парадигмы, развитие парадигмы — кризис парадигмы, разброд и шатания — возникновение новой парадигмы — ре-интерпретация данных старой парадигмы в рамках новой — консолидация вокруг новой парадигмы — и так далее.
Мне кажется важным, что точно так же, как новая научная теория может быть успешной только если она сможет дать объяснение всем фактам, которые объясняла старая — точно так же и новая культура должна успешно ассимилировать в себя все культурные артефакты, оставшиеся ей в наследство от старой. Мое предположение состоит в том, что только при этом условии новая культура будет успешной, в некотором смысле, «здоровой».
Мне кажется, у многих людей (и у вас, как мне кажется, тоже) есть какой-то такой образ, что культура должна развиваться линейно — ввысь. Но это противоестественно — все действительно живое развивается проходя через череду кризисов. Чтобы найти новый смысл, и новое видение — часто просто необходимо, чтобы старое умерло. Как бы красиво и величественно оно не было — особенно если старое очень красиво и величественно — в какой-то момент нужно чтобы оно потерпело поражение. Умерло, сгнило, и разложилось. Нужно чтобы люди, которые будут создавать новую культуру — пережили это как личностный кризис, наблюдали это разложение, и пройдя через это нашли внутри себя то, что будет действительно их культурой.
А то, что говорите вы (и наши просвященые депутаты) — похоже на попытку забальзамировать нового Ильича. Старая культура умирает, и с этим ничего не сделать. Новая — когда сформируется — наверняка переоткроет и впитает в себя значительную часть достижений старой. Никуда не исчезнут ни Достоевский, ни Пушкин, ни Плутарх — но, наверняка, в рамках новой культуры они будут читаться иначе, и пониматься тоже иначе.
Готовы взяться?
У ООПшного подхода есть так плюс как самодокументируемость. Что такое «словарь функций»? — как я могу догадаться, что в данном конкретном случае это «почта»? Только поддерживая консистентные имена переменных? Если в какое-нибудь место ваша «почта» будет передана просто как arg3 — что я смогу понять про ее назначение?
В то время как, скажем, интерфейс SubscriptionTopics говорит мне уже гораздо больше — независимо от того, каким путем он ко мне попал. Я даю имя сущности, которая мне нужна — в то время как вы называете реализацию сущности: в одном месте словарь функций может быть «почтой», в другом — частью конечного автомата — это очень разные сущности, а реализация одна.
отсутствие мозговнедостаточная грамотность у разработчиков пагубно сказалось на производительности.Если все-таки отвечать на вопрос — и да, и нет. «Честный» выброс исключения действительно недешев — по многим причинам. Но если ваш метод действительно зовется часто, то на стадии агрессивной оптимизации он будет, с хорошей вероятностью, заинлайнен по самые помидоры — так, что в реальном коде и выброс и поимка исключения окажутся в одном фрейме стека, и компилятор сможет их соптимизировать до передачи информации об ошибке в локальной переменной. Тогда это будет почти бесплатно. На хабре была хорошая статья Алексея Шипилева с подробными бенчмарками этой ситуации в разных случаях — поищите, оно того стоит.
Более того, есть методы соптимизировать проброс исключения и в более общих случаях — например, можно переиспользовать единственный синглетонный экземпляр исключения, и перегрузить fillStackTrace() чтобы не дергать нативный код. Мне вспоминается, что была какая-то неплохая библиотека, использовавшая такого рода трюки чтобы потом заложиться на исключения как способ управления control flow (о ужас, да?) — и ничего, нормально даже работало. Но это, конечно, то самое исключение, что подтверждает правило — вообще-то так делать не стоит.
Пока у вас нет веских причин оптимизировать — не надо оптимизировать то, что хорошо написано.
Очень смущающее построение фразы. Другие процессоры не могут иметь «более свежие» данные, чем те, что есть у «владельца» (Owner). Может быть один кэш, содержащий строку в O, а остальные кэши либо вообще ее не содержат, либо содержат в S — и тогда ее содержимое скопировано с того самого кэша, который владелец. Подробнее тут
Хорошо, продемонстрируйте мне практическое применение вашего определения. Дано:
Покажите, пожалуйста, стоимость написания в каждом случае, стоимость поддержки в каждом случае, и стоимость ошибки в каждом случае — для какого-то из ваших проектов, по вашему выбору. Так, чтобы можно было сравнить, и посчитать сумму, и сделать обоснованный вывод — какой из стилей считать излишним перфекционизмом, какой — непрофессиональностью, а какой как раз зрелым профессионализмом — для данного конкретного проекта.
Мне вот правда интересно, как вы на практике применяете такие высокоуровневые абстракции, когда речь заходит о таких конкретных низкоуровневых вещах?
Я отвечал вам на вопрос, почему (возможно) в classlib сделано — и оставлено — как есть. Я не считаю, что использование NPE это прямо таки «ненормально» — я считаю, что IAE лучше — потому что
а) более явно и прямо выражает намерение программиста (не «встретил нулевой указатель», а «некорректный аргумент»)
б) позволяет явно отличить предусмотренную проверку с выборосом исключения от случайного выброса исключения в результате реального разыменования.
Это не те аргументы, чтобы прямо руку давать на отсечение и горло грызть. Более того, одного аргумента против — что classlib использует NPE — уже достаточно. Но не потому, что авторы classlib как-то принципиально умнее, и не могли ошибаться — а именно потому, что массовое применение само по себе создает стандарт. Это как с DVD vs BlueRay — кто первый заполучил массовую популярность, тот и выиграл, и достоинства и недостатки самой технологии — если они не суперкритичны — отходят на второй план. И уже не важно, что изначальное преимущество популярности могло получиться случайно, или по ошибке, или даже незаконным всепланетным еврейским сговором.
>Знаю, я сам из таких людей.
И у вас, конечно, есть бенчмарки, показывающие существенную деградацию производительности вашего приложения в версии с новыми строками? И дизайн этих бенчмарков, конечно, исключает другие причины деградации при смене JDK — кроме смены .substring()?
>А не нравится этот пример, вот вам другой.
Меня эта ситуация самого дико удивила в свое время — там еще с DataSource была похожая петрушка. Однако, еще раз повторяю — одно дело в одном конкретном интерфейсе (который, в общем-то, больше предназначен реализовываться авторами jdbc-драйверов, а не прикладными программистами) нарушить совместимость. А другое — изменить некий стандарт, который commonly used во всей classlib. И ради чего? — ради чуть-чуть большей согласованности? Я ссылался же (а ниже в комментах приводят даже прямые цитаты) — корифеи джавы вон уже несколько лет назад признали, что проверяемые исключения не стоили свеч. Бонус от перехода на непроверяемые, хоть где-то и спорный — все-таки на порядок более весом, чем от перехода NPE->IAE. Тем не менее же никто не чешется переводить classlib на непроверяемые исключения. Более того, я даже не слышал, чтобы новые части стандартной библиотеки разрабатывались с непроверяемыми — т.е. старый стандарт продолжает быть стандартом, хоть даже его авторы уже в нем разочаровались.
Лично я сначала тоже использовал .checkNotNull() для проверки на null, и checkArgument для остального. Но чем больше я у себя внедрял Preconditions, тем больше мне резали глаз сочетания типа
почему в первом случае NPE, а во втором IAE? Смысл ведь один и тот же — такие аргументы методу не подходят. В конечном счете я решил оставить NPE для сторонних библиотек, а в своем коде фиксировать, что невалидные аргументы это всегда IAE.
У checkNotNull появится преимущество когда заработают @ NotNull — тогда с checkArgument придется расставаться, наверное. Ну или переписать checkNotNull так, чтобы бросал IAE :)