Вхід і реєстрація
Про роботу · 28 грудня 2017, 15:51 5382
Maxim Pilipenko, Full Stack Developer в Sitecraft

Не смог ответить на вопрос интервьювера: catch vs onRejected

Только что было интервью по скайпу. Первый раз проходил его не в офисе. Вроде не нервничал, но прошло все ужасно. Хуже еще не было. Хотел поинтересоваться, кто смог бы ответить на этот вопрос(устно) и как. Вопрос развернуто: «В чем разница между обработкой ошибки в кинутой в промисе с помощью второго аргумента к then(или onRejected handler) и catch». Я ясное дело глянул в гугле уже и думаю что лучше было бы это было скинуть пример кода конкретного. Так было бы понятней. Но это опровдания... Просто не успокоюсь, пока не поделюсь с кем то. Еще был вопрос — "Что может быть причиной unhendledRejection если если есть правильно зарегистрированный errorHandler с помощью catch"(не дословно). Мне этот вопрос показался странным. Но наверно я просто не правильно понял его.

Теми: співбесіда
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Artyom Krivokrisenko 30.12.2017 11:18

Это вопрос с подвохом.

Правильный ответ: В стандарте Promise/A+ отсутствует catch, поэтому его поведение зависит от того кто и как делает реализацию. 99% интервьюверов после этого ответа сливаются и не могут задать уточняющий вопрос.

Відповісти
Підтримати
Nikita Galkin GDE, Fractional CTO/Principal Engineer, Node.js Tech Speaker 30.12.2017 01:37
Просто не успокоюсь, пока не поделюсь с кем то

 Чем именно ты хотел поделиться? Тем что на конкретном проекте, интересуются малозначимой с твоей точки зрения тонкостью работы промисов?

С моей точки зрения, на проекте, где код написан на промисах, а не на async/await это не тонкость, а базовое знание. Без его понимания, ты не сможешь отлавливать в нужном месте цепочки промисов ошибки. Ниже писали об этой проблеме промисов — их паршивой читаемости. Поэтому, скорее всего вопрос был абсолютно обоснован.

А может ты хотел поделить тем, что все

Все прошло ужасно

? Ведь это ужасно, что тебе не надо было ехать в офис, что на тебя потратили время, что ты получил первый опыт прохождения удаленного интервью, что теперь ты знаешь рынок труда немного лучше.

Или может ты хотел поделиться темой, на которую прореагируют и будет о чем писать на интересном.айти? Это мысль ко мне всегда приходит, когда появляется очередной аноним.

Відповісти
Підтримати
Maxim Pilipenko Full Stack Developer в Sitecraft 30.12.2017 01:48

Именно тем что прошло ужасно. Несмотря на все обективные плюсы, как получение опыта, я все равно был расторен. Эмоции не имеют ничего общего с рац. мышлением. И увидев первый же коммент с поддержкой мне стало намного легче. Чесно.
П.С. Не то что бы я после интервью рыдал, но просто не по себе было.

То что это базовое знание я нигде не спорил и написал, что это все вообще оправдания в конце поста.

Что такое интересном.айти я не знаю.

Відповісти
Підтримати
Nikita Galkin
Євген Козлов Front-end developer в SoftServe 30.12.2017 10:45

базовое — это что из .then можно вернуть новый промис.
озвученная фишка, если раньше о таком не задумывался, запоминается сразу, как только с ней встретишься. например, как укороченное выполнение логических выражений.

Відповісти
Підтримати
Nikita Galkin
Андрей Литвинов C Señor 29.12.2017 23:11

С одной стороны ответ гуглится на раз при необходимости, но это ведь базовые понятия, которые даже ждун должен знать достаточно глубоко, если JS — это основной язык.

Відповісти
Підтримати
Anton Melnyk Software Engineer в Printify 30.12.2017 16:59

Не назвал бы это базовыми понятиями для джуна.

Відповісти
Підтримати
Андрей Литвинов
Андрей Литвинов C Señor 30.12.2017 17:23

Я когда искал работу джуном C# хорошо понимал что такое Task и внутрятку .NET в целом. Как без этого можно писать нормальный код?

Відповісти
Підтримати
Anton Melnyk
Platan 30.12.2017 17:26

Ты не сравнивай джнуа C# и джуна JS.
Джун C# (как и джавист) это минимум 1,5 года комерческого опыта. И базовое понимания платформы, стандартных библиотек, нескольких основный фреймворков.
Для джунов в JS требования зачастую несколько меньше.

Відповісти
Підтримати
Андрей Литвинов
anonymus ps 30.12.2017 18:19

Да такие же у джс требования, просто специалистов в этой сфере кот наплакал

Відповісти
Підтримати
Platan
Gennady Dogaev full-stack web developer (freelance) 30.12.2017 18:32

Это очень спорно, относить данный вопрос к базовым или нет. Если исходить из того, можно ли без этого знания работать в-принципе — то наверное можно, и тогда это действительно не базовые понятия. Особенно если учесть что во фронте длинные цепочки промисов не часто нужны. Но с другой стороны — оно намного лучше когда такую тонкость знаешь и сразу пишешь так чтобы не наступить на грабли.

Відповісти
Підтримати
Anton Melnyk
Gennady Dogaev full-stack web developer (freelance) 29.12.2017 12:57

Как здесь уже писали,

The difference is subtle, but extremely useful. Promise rejections skip forward to the next then() with a rejection callback (or catch(), since it’s equivalent). With then(func1, func2), func1 or func2 will be called, never both. But with then(func1).catch(func2), both will be called if func1 rejects, as they’re separate steps in the chain.

Это значит что в случае второго аргумента к then, если в первом аргументе возникнет ошибка, она не поймается. В случае catch — поймается. Можно взять себе за правило всегда использовать catch, и не задумываться об этой тонкости. Кстати, если catch (или второй аргумент then) вернет промис — цепочка не прервется. Иногда (изредка) это удобно использовать.

На второй вопрос — наверное если errorHandler выбросит исключение. Но тут я уже не очень уверен — не сталкивался на практике с unhandledRejection.

В целом, вопросы конечно чтобы «завалить» — даже вон сырные синьоры доу не все знают ответ. Об этом обычно в разных мануалах и статьях пишут мало и поверхностно, но на практике вылезти может, поэтому занать не бесполезно

Відповісти
Підтримати
Gennady Dogaev full-stack web developer (freelance) 29.12.2017 12:43

Это не сахар, это сыр. Вкусный, кстати.

Відповісти
Підтримати
anonymous
Олексій Пєніє 29.12.2017 09:17

Тебя просто собеседовал дурак — вот и весь сказ. Если ты не архитектор проекта, тебе это нахер не сдалось — писать ты будешь ровно в том стиле, в котором пишет вся команда. По логике разницы нет никакой, есть разница в удобочитаемости кода. А это прежде всего — весь код написанный в одном стиле.

Сами промисы — геморой редкостный с точки зрения удобочитаемости, особенно вложенные, не говоря уже о зацикленных. Мозг просто запутывается в том, что находится в данных конкретного промиса, со всеми последующими багами.

Как правило, структуры if — elseif — else и им подобные читаются на порядок легче. Почему?
1) Мозг отсекает всё лишнее, он прекрасно обучен контекстной фильтрации, это его нативная способность.
2) Покрытие логикой чётко видно, не важно, что там ничего другого и не могло быть (в теории), важно что здесь и сейчас не нужно вспоминать и гадать — вот оно, на блюдечке, в коде!

Если у промиса приличный кусочек логики, то приходится делать финт ушами: сохранять логику (фнукцию) или сам промис в переменную, которой уже пользоваться в дальнейшем. С точки зрения кода конечно ересь, но языки программирования не для кода пишутся — они для людей! И мозг отлично понимает ИМЕНА переменных, и правильно данное имя — залог читаемости кода.

Только дурак или конченая сволочь может собеседовать с целью завалить. Не нужен человек — хера ты его на собес зовёшь? Вот когда компании перестанут оплачивать саму имитацию бурной деятельности, а будут платить только за результат — ой, сколько «вахтёров» пойдёт искать работу!

Відповісти
Підтримати
Gennady Dogaev full-stack web developer (freelance) 29.12.2017 12:41

Зачем писать простыню ереси, если сам не понимаешь о чём речь? Прикинь если каждый фронтендер будет со своей экспертизой отвечать на вопросы по Java?

Відповісти
Підтримати
Олексій Пєніє
Vitaliy Fedoriv Java Developer 29.12.2017 15:54

Буває. Мене іноді реально плющить від спроб зрозуміти логіку promises, якщо вона хоч трохи нетривіальна. При тому що в Java також можна реактивне програмування юзати. Але при JS приходиться собі нагадувати: а ніззя окремий потік, ця фігня однопоточна, по іншому не можна і т.п. Стара собака, нові фокуси :)

Відповісти
Підтримати
Gennady Dogaev
anonymus ps 29.12.2017 16:00

Уже промисы не в моде, сейчас observables все хотят, а там помимо success и error есть понятие completed, которое может менятся операторами, и некоторые на него зависят, а оно само по себе не очень явно

Відповісти
Підтримати
Vitaliy Fedoriv
Олексій Пєніє 29.12.2017 17:16

Що значить «можна»? Є задачі які інакше як через реактивне програмування не вирішуються. І це сталося задовго до того як Java на світ народилася.

А на JS не раз ловив здивований визг браузера «а що таке volatile??»

Відповісти
Підтримати
Vitaliy Fedoriv
Олексій Пєніє 29.12.2017 17:11

Я могу задать буквально 3-4 вопроса по Java, чтобы сказать готов человек писатькодбля, или будет говнокодить чупакабру из шаблонистых шаблонов.

Я понимаю о чём речь, и разумеется держал в руках JavaScript. Я не берусь сказать что у меня огромная экспертиза во фронтенде, но на уровне вменяемой бизнес-логики проблем не вижу. И уж точно не вижу проблем с промисами по сравнению с их основным головняком — паршивой читаемостью готового кода, от чего растут баги у кодеров.

То что подобный вопрос задавался устно — либо дурость, либо наглость собеседующего. Вот ты за компом с интернетом умный, а попробуй пройти собес у подобного супермозга, что-либо недавно выучившего — поймёшь насколько глубока задница.

А если фронтендер будет знать ответы по Java — могу только поздравить с фуллстеком. Даже если он будет знать 25% ответов по Java, ему ровно ничего не стоит узнать остальное, если в команде есть разраб по Java.

Я же почему и говорю — нет ровно никакого резона СПРАШИВАТЬ то, что не является критическим в работе. Эти вопросы не покроют и 0.1% требуемых знаний, зато запросто отсеют нужных людей, которые с вопросом просто не сталкивались. К примеру, если человек всегда писал правильно — какой смысл спрашивать его как было неправильно, он не знает! А если писал неправильно — проще дать приказ писать вот так-то и вот так-то, а не угадывать как он привык.

А насчёт ереси — давай-ка сам расскажи, чем на работе занимаешься. Как часто ты делаешь то, чего не знаешь (и лезешь в документацию). Как часто ты оказываешься неправ, и потом переписываешь сделанное? Как часто уже через год ты не помнишь то что сам писал и зачем? И всё-таки ради интереса, пройди несколько собесов — просто чтобы понял, что твоё умение писать код львиная доля интервьюеров вообще не оценивают!!! А то что они спрашивают — релевантно как ласты на танцполе.

Відповісти
Підтримати
Gennady Dogaev
Gennady Dogaev full-stack web developer (freelance) 29.12.2017 18:02
И уж точно не вижу проблем с промисами по сравнению с их основным головняком — паршивой читаемостью

Учитывая асинхронность многих функций — или промисы, или callback hell (и hell в этом случае — не преувеличение)

Вот ты за компом с интернетом умный

На первый вопрос я ответ знаю и без интернета, так как с промисами работаю каждый день на фронте и немножко игрался с нодой, где асинхронна вообще почти каждая функция. На второй (про unhandled rejection) — у меня есть только предположение, на практике я с таким не сталкивался.

а попробуй пройти собес у подобного супермозга, что-либо недавно выучившего — поймёшь насколько глубока задница.

Когда первую работу искал — проходил, да. В 2008 спрашивали про хранимые процедуры в mysql. К счастью не взяли туда где спрашивали. Уже потом мне стало понятно, что это были вопросы чтобы показать кто тут умный, а на практике никто и не знал как хранимки писать, и в 99% случаев их писать не нужно. Но я джуном был, а хранимые процедуры экзотикой. А вот промисы в 2017 экзотикой не являются даже на фронте. А уж в ноде и подавно. Не, ну в-принципе если ТС джун — можно в первый день работы сказать «пиши только так, некогда объяснять», но хотелось бы чтобы программист на жс такие вещи всё-таки знал. Так что вопрос легитимный, в отличии от «что будет если сложить объект с массивом» (будет хрень, и это логично, а какая конкретно неважно) или «какие параметры принимает дикаяФункцияКоторуюНиктоНеИспользует» (есть google и MDN).

А насчёт ереси

Поясняю про ересь. Ты писал:

Сами промисы — геморой редкостный с точки зрения удобочитаемости, особенно вложенные, не говоря уже о зацикленных. Мозг просто запутывается в том, что находится в данных конкретного промиса, со всеми последующими багами.

Как правило, структуры if — elseif — else и им подобные читаются на порядок легче.

Ересь в том, что промисы не имеют отношения к if/else. Они были созданы и используются чтобы заменить коллбеки, потому что если вложенности нет — читается всё ок, если в колбек вложен другой — уже так себе, а если вложить ещё один — получается ад. Ну и ТС пришел наверное понять как ответить правильно, а не чтобы его пожалели и рассказали что собеседующий мудак.

Відповісти
Підтримати
Олексій Пєніє
Sergei Epatov Staff RnD Engineer в Apptopia 29.12.2017 18:41

В человеческих языках выбор куда больше, чем два варианта. Проактор, реактор, async/await, coroutines, зеленые потоки, или вообще цикл с явным конечным автоматом.

Відповісти
Підтримати
Gennady Dogaev
Олексій Пєніє 03.01.2018 09:35

В человеческих языках абсолютно любое слово является шаблоном. Что лишний раз доказывает, что все эти шаблоны проектирования — не иначе как модное дрочево на выдумку кодеров из авторитетной фирмы.

О том что не существует никаких провидцев — зачем знать? Такие же программисты, придумавшие модель как им удобно делать то, что писалось именно в те года. А что программирование вообще-то охватывает львиную часть человеческой деятельности, и код должен исполнять алгоритмы предметной области — так это теоретикам вообще неинтересно. Они привыкли, что если как попугаи кукарекать вслед авторитетам — их сочтут умными.

Відповісти
Підтримати
Sergei Epatov
Олексій Пєніє 03.01.2018 09:31

Если промис короткий — это читаемо. Но как правило на коллбэках висит огромный пласт логики. В результате момент вызова и момент обработки исключительных ситуаций — разнесены как коленки Саши Грей.

Собеседующий мудак уже потому, что подобные вопросы на словах не задаются. Как минимум распечатка кода нужна. В отличие от кандидата, который должен уметь только то зачем его берут, интервьюер должен владеть технологиями проведения собеседования, уметь отсекать всё лишнее за счёт СВОЕЙ готовности.

Что сделал этот клоун: выставил свою неготовность как неготовность кандидата. В результате не смог протестировать, и вместо собеседования — подрочил себе ЧСВ. Вот только не говори, что распечатать код на бумажке или предоставить ноутбук — нужно быть гуру международного класса. Наоборот! Неумение работать с людьми должно быть барьером к такой работе вообще.

К нашим баранам: казалось бы, если промис получается длинным, значит надо в промисе оставить базовую обработку, а всё остальное вышвырнуть в функцию. Красота! Но ровно до тех пор, пока в отрыве от промиса не встречаешь эти функции, пытаясь понять что они делают и куда гадят. Я это сплошь и рядом вижу. Особый шик — это как именуют эти функции. И писк моды — разнести функцию и промис по разным файлам.

Как я делаю: Создаю не метод, а промис, в отдельную переменную, со вменяемым именем и с пояснением зачем он. То есть де-факто тот же самый коллбек, но красиво обёрнутый в промис, так чтобы ежу понятно было, что иначе как внешними данными сей клитор не стимулируется. И разумеется, все исключения которые могут возникнут в процессе обработки данных — там же и ловятся, и никуда дальше не идут. Впрочем, бывают и исключения — при финансовых транзакциях имеет место пирамидальная блокировка интерфейса, и эксепшены должны всё же быть пересозданы, дабы интерфейс кошерно разблокировался.

Відповісти
Підтримати
Gennady Dogaev
Valentin Nechayev уповноважений по милицях в Дарницькі печери 30.12.2017 21:17
Сами промисы — геморой редкостный с точки зрения удобочитаемости, особенно вложенные, не говоря уже о зацикленных. Мозг просто запутывается в том, что находится в данных конкретного промиса, со всеми последующими багами.

Это потому, что ты думать не хочеш. Промисы банально понимаются, если представлять действия в них графически, в виде блок-схем или любого аналога. Да-да, стрелочки рисовать.

Если есть в них проблемы, то в неровности API — например, что начальная функция и продолжатели по then/catch должны отдавать свои результаты заметно по-разному. Но не в самой идее связи callbackʼами.

Если у промиса приличный кусочек логики, то приходится делать финт ушами: сохранять логику (фнукцию) или сам промис в переменную, которой уже пользоваться в дальнейшем.

У него и так вызываются функции, и что?

Как правило, структуры if — elseif — else и им подобные читаются на порядок легче. Почему?

Потому, что ты к ним привык.

Если у промиса приличный кусочек логики, то приходится делать финт ушами: сохранять логику (фнукцию) или сам промис в переменную, которой уже пользоваться в дальнейшем.

Приведи пример. Пока слабо понятно, что тебе в этом «не так».

Только дурак или конченая сволочь может собеседовать с целью завалить.

Это другая тема, и я был бы в принципе согласен, но in practice they differ.
Например, заказ на человека сделал Вася, а собеседует его подчинённый Петя, у которого совсем другие интересы в фирме (и первый из них — подсидеть Васю). Впрочем, ты и так сам всё знаешь, только чего-то сейчас не хочешь вспоминать...

Відповісти
Підтримати
Олексій Пєніє
Podoprigora Alexandr front-end developer в freelace 28.12.2017 18:40 
There's nothing special about catch(), it's just sugar for then(undefined, func), but it's more readable.

The difference is subtle, but extremely useful. Promise rejections skip forward to the next then() with a rejection callback (or catch(), since it's equivalent). With then(func1, func2), func1 or func2 will be called, never both. But with then(func1).catch(func2), both will be called if func1 rejects, as they're separate steps in the chain. Take the following:

developers.google.com/...​s/promises#error_handling

Не нужно сильно переживать, это нормально, у вех случаются «затупы» на интервью, в следующий раз получится.

Відповісти
Підтримати
Podoprigora Alexandr front-end developer в freelace 28.12.2017 19:27

Для интереса, напишите список вопросов интервью, думаю будет интересно тем кто готовится.

Відповісти
Підтримати
Podoprigora Alexandr
Олексій Пєніє 29.12.2017 09:52

Это «нормально» только на постсовковом пространстве — спрашивать на собеседовании то что сам только что где-то вычитал. Тем более спрашивать без примера кода.

Как раз гнать разные по природе ошибки в один catch, чтобы потом их там как-то отличать — вот это антипаттерн. Просто срать в один лог все ошибки без разбора — за это надо наказывать типичной задачей — найти в логе на 200Мб за сегодня что необычного по сравнению с предыдущими 2Гб за вчера.

Відповісти
Підтримати
Podoprigora Alexandr
Podoprigora Alexandr front-end developer в freelace 29.12.2017 14:20
Это «нормально» только на постсовковом пространстве — спрашивать на собеседовании то что сам только что где-то вычитал. Тем более спрашивать без примера кода.

Для мидла, претендующего на рейт > 20$ это нормальные вопросы, сейчас информация доступна как никогда, нужно прокачивать себя, разбираться в деталях.
Да, раньше было проще ))

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 29.12.2017 17:24

А кто тебе таки сказал, что люди изменились биологически?? То что информация доступна — не значит что она применяется ежедневно. А то что ты ежедневно не применяешь — ты и не знаешь, ты находищь при необходимости.

И когда ты практик, ты точно не знаешь 5 способов поменять местами значения переменных без промежуточной. К примеру, я знаю 0 способов это сделать, я создаю промежуточную переменную. А тем кто попробует сделать иначе, могу зарядить в табло ботинком, просто за то что код абсолютно нечитаемый, то есть придётся переделывать — и переделывать не маленький кусочек, а жирный кусок логики, просто потому что где-то что-то глючит, и непонятно как оно должно было работать.

Вот как раз на завтра у меня подобная задача с чужим кодом. Даже браться сегодня не решаюсь, знаю что целый день уйдёт.

Відповісти
Підтримати
Podoprigora Alexandr
Олександр Шпак Oarsman в Self Employed 30.12.2017 01:47
И когда ты практик, ты точно не знаешь 5 способов поменять местами значения переменных без промежуточной.

Спочатку треба спитати, а що за задача, що в ній вимагається така операція?

Відповісти
Підтримати
Олексій Пєніє
Євген Козлов Front-end developer в SoftServe 30.12.2017 10:47

в сортировке пузырьком может пригодится.

Відповісти
Підтримати
Олександр Шпак
Євген Козлов Front-end developer в SoftServe 30.12.2017 12:26

чтоб местами поменять соседние элементы.

Відповісти
Підтримати
Artyom Krivokrisenko
Artyom Krivokrisenko 30.12.2017 12:32

Зачем это делать когда можно поменять старым добрым способом через временную переменную?

Відповісти
Підтримати
Євген Козлов
Євген Козлов Front-end developer в SoftServe 30.12.2017 12:35

не понял вопроса. да, можно.
обмен переменными вообще мало, где можно притулить. я отвечал в контексте «вообще может использоваться». а тут, внезапно, «а зачем, если можно...»

Відповісти
Підтримати
Artyom Krivokrisenko
Artyom Krivokrisenko 30.12.2017 12:41

Вопрос в том, зачем в сортировке пузырьком обмен двух переменных именно без промежуточной переменной, когда то же самое быстре делается с промежуточной

(читайте внимательнее сообщение на которое вы отвечали — dou.ua/...​rums/topic/22670/#1252329)

Відповісти
Підтримати
Євген Козлов
Євген Козлов Front-end developer в SoftServe 30.12.2017 13:00

как это — быстрее?
быстрее, чем a,b = b,a?

Відповісти
Підтримати
Artyom Krivokrisenko
Valentin Nechayev уповноважений по милицях в Дарницькі печери 30.12.2017 14:51

Типичная реализация кода «a, b = b, a» внутри себя будет использовать две промежуточные переменные, так что это по любому не будет лучше.

Відповісти
Підтримати
Євген Козлов
Євген Козлов Front-end developer в SoftServe 30.12.2017 18:44

писать быстрее.
читать быстрее.
понять быстрее.
выполняется медленнее, допустим.
но в каком случае в эту операцию упирается производительность алгоритма? я не могу представить.

и насчет двух дополнительных переменных мне кажется спорным.
a = c не использует же еще одну дополнительную переменную, правда?
ps впрочем,в джс так не получится, надо будет
[a,b] =[b, a]
таки одна дополнительная переменная.

Відповісти
Підтримати
Valentin Nechayev
Valentin Nechayev уповноважений по милицях в Дарницькі печери 30.12.2017 21:12
но в каком случае в эту операцию упирается производительность алгоритма? я не могу представить.

Например, когда копирование дорогое (вполне возможно, если элемент не плоское данное, а объект с поведением). (Тут я не ограничиваю контекст JS’ом или чем-то ещё типовым.)

Алгоритмы для подобного случая или проектируются на минимизацию обменов, или вообще (метод универсального ножа) работают с указателями, а если нужно копирование, то делают его один раз по результату сортировки.

и насчет двух дополнительных переменных мне кажется спорным.
a = c не использует же еще одну дополнительную переменную, правда?

Не использует. Но вот подобное множественное присвоение чуть менее чем всегда требует, чтобы результат был идентичен тому, что вначале накопировали все правые части, а потом присвоили всем левым. Иначе оно такое не имеет смысла и достаточно присвоения по одному.
А дальше вопрос, кто как может оптимизировать это. Но я бы тут не рассчитывал на интеллект компиляторов.

ps впрочем,в джс так не получится, надо будет
[a,b] =[b, a]
таки одна дополнительная переменная.

По сути это те же две — маскировка в виде списка не меняет сути.

Відповісти
Підтримати
Євген Козлов
Євген Козлов Front-end developer в SoftServe 30.12.2017 22:32

теоретически я полностью согласен:
для языка без возможности доступаи присвоения по ссылке обмен значениями переменных будет болезненным. при любой реализации(хоть промежуточная переменная, хоть syntax-based).
в знакомых мне условиях(js, C, PHP etc) чем короче и однозначней запись — тем лучше.
и пляски с XOR будут проигрывать вообще всему, а «a, b = b, a» будет на первом месте.
если у вас иной опыт, поделитесь, плиз

Відповісти
Підтримати
Valentin Nechayev
Bot Bot 28.12.2017 15:55

Разве ошибки не должны ловиться через catch?

Відповісти
Підтримати
Bot Bot 28.12.2017 15:58

уже прочитал ответ ниже со SOF :-)

Відповісти
Підтримати
Maxim Pilipenko
Maxim Pilipenko Full Stack Developer в Sitecraft 28.12.2017 15:54

Да. Я уже прочитал. Но спасибо.

Відповісти
Підтримати
Roman Rybakov
Костя Третяк 28.12.2017 17:28

Цікаво що ви зрозуміли з прочитаного. Яка між ними різниця? Чому один кидає помилку, інший ловить?

До речі, користувач, чия відповідь позначена як «прийнята», поганенько пояснив суть, заблукав кудись...

Відповісти
Підтримати
Maxim Pilipenko
anonymus ps 28.12.2017 17:42

Там ясно как Божий день все, что еще объяснять?

Відповісти
Підтримати
Костя Третяк
Костя Третяк 28.12.2017 17:44

Там заплутано написано і не пояснено суті. Гляньте мій код нижче, там я позабирав усе зайве. Заберіть один із then і помилка не зловиться, але коли є два then — помилка ловиться.

Відповісти
Підтримати
anonymus ps
anonymus ps 28.12.2017 18:53

Если человек знает что .catch это про сахар то все будет ясно, конено если у человека есть мозг

Відповісти
Підтримати
Костя Третяк
Костя Третяк 28.12.2017 17:39

Чіткіше буде зрозуміло, коли розберетесь чому ось таке доповнення того проміса, чия помилка не ловилась спочатку, тут ловиться:

Promise.resolve()
.then
(
  () => { throw new Error('Error number one occurs'); },
  err => console.log('catch by number one handler', err)
)
.then
(
  () => { throw new Error('Error number two occurs'); },
  err => console.log('catch by number two handler', err)
);
Відповісти
Підтримати
Maxim Pilipenko
Олексій Пєніє 29.12.2017 09:33

Можливо тому, що це різні помилики, і вони мають оброблятися по-різному? Так, декілька try-catch, якщо є очікувана помилка.

А от генерація помилки — то вже моветон. Хоча є проекти де саме така поведінка є загальним стилем. Але їх меншість. В більшості випадків, якщо проміс відловив очікувані дані, а не код помилки — то then вже сам має розбиратися із тими даними, а не напрягати зовнішній catch.

Лише говнокодери тупо кидають в лог всі помилки, не розбираючись що в них. Найти потім щось в тих логах, особливо коли не знаєш що шукати — ото вже гємор!

Відповісти
Підтримати
Костя Третяк
Костя Третяк 29.12.2017 09:42

На скільки я зрозумів, ви думаєте, що ось цей мій код — є рекомендацією, так? — Ні, насправді я очистив той код, що у прикладі від зайвих частин і додав до нього другий then лише в якості наглядного прикладу «Що відбувається в коді».

Якщо ви запустите цей код, то логи чітко показують з якого саме then помилка кидається, і який catch їх обробляє.

У прийнятій відповіді на Stackoverflow чувак хоча й правильно спочатку сказав про:

Your first piece of code wont catch the error because the error handler is in the same .then where the error is thrown

Але далі його понесло злегка не туди, бо різний ситаксис, про який він говорить, не пояснює суті. А суть я спробував пояснити ось тут stackoverflow.com/a/48011082/1716560

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 29.12.2017 09:55

Та це зрозуміло, що сама суть питання — бюрократична. Тобто оце — кошерні патерни, оце — некошерні, а те що реально буде написано — індусу не насниться.

Відповісти
Підтримати
Костя Третяк
Костя Третяк 29.12.2017 09:56

О боже, Льоха, лише ранок почався... чи це ще з учора залишилось? Так довго не пускає?

Відповісти
Підтримати
Олексій Пєніє
Олексій Пєніє 29.12.2017 09:58

Та нє, я просто читав реально як його пишуть, при тому пишуть люди які вже багато років тим займаються. І мене відверто дивують прецеденти, коли валять кандидата на питаннях «з якого кінця яйця бити».

Відповісти
Підтримати
Костя Третяк
anonymous 29.12.2017 15:57
А суть я спробував пояснити ось тут stackoverflow.com/a/48011082/1716560

кстати, это тоже неверно. Точнее, это верно только в случае resolve.
В случае реджекнутого промиса:
— rejectedPromise.then(onSuccess, onError) вызовет только onError
— rejectedPromise.catch().then() вызовет по очереди и .catch, и .then

Відповісти
Підтримати
Костя Третяк
Костя Третяк 29.12.2017 16:00
rejectedPromise.catch().then() вызовет по очереди и .catch, и .then

Чому ви так думаєте? Десь про це говориться у документації, чи може є приклад, що про це свідчить?

Відповісти
Підтримати
anonymous
anonymous 29.12.2017 16:09

Я не думаю, а знаю. Для этого достаточно просто понимать, как работают промисы.
Понятия не имею, говорится об этом в докуметации или нет.

Пример? Могли бы и сами проверить.
Но если лень, то возьму ваш пример и заменю resolve на reject

Promise.reject(’some error’)
.catch
(
err => console.log(err)
)
.then
(
() => { throw new Error(’Error occurs’); }
)

И что будет в консоли? Правильно: сначала «some error», а потом «Error: Error occurs»

Відповісти
Підтримати
Костя Третяк
Костя Третяк 29.12.2017 16:16

А, ви говорите про режект самий перший, я думав що в then. Так, якщо самий верхній режектиться, то вони не ідентичні. Я ж написав приклад з першим резолвом...

Відповісти
Підтримати
anonymous
anonymous 29.12.2017 16:19

А, ну все норм — к общему мнению пришли. Сори за излишний гон, если что :)
Да, в случае резолва катит, но вот с реджектами интереснее все :)

Відповісти
Підтримати
Костя Третяк
Valentin Nechayev уповноважений по милицях в Дарницькі печери 30.12.2017 21:34

Ну а что тут такого — catch создал новую ветку обработки ошибки в виде промиса. Теперь в этой ветке свои успехи и неудачи, ничуть не связанные с исходными...

Відповісти
Підтримати
anonymous
anonymous 30.12.2017 21:55

В промисах вообще ничего «такого» нету, но постоянно кому-то что-то непонятно (зачастую базовые вещи) :)

Відповісти
Підтримати
Valentin Nechayev
Євген Козлов Front-end developer в SoftServe 30.12.2017 22:34

охохо, в эту фразу вообще почти любую концепцию можно подставить и будет справедливо

Відповісти
Підтримати
anonymous
Maxim Pilipenko Full Stack Developer в Sitecraft 28.12.2017 15:50

Коментар порушує правила спільноти і видалений модераторами.

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.