WinAPI сделано в лучших традициях того времени, в которых несомненно есть рационализм. Но проверку кода возврата легко пропустить и программисту за это ни чего не будет, а с проверками код быстро превращается в месиво из бизнес-логики и control flow. Сигнатуры таких функций не поддаются стандартизации — out параметры могут быть в любом порядке и количестве, а вызовы не compose'ятся между собой. Поскольку out структура не принадлежит вызванной функции, довольно легко накосячить с потокобезопасностью. Собственно, от этого и пытались уйти, изобретая исключения.
Идеоматически в примере 2 кидают StopIteration. Это позволяет отличить такой вот псевдо-goto от прочих исключений, которые могут быть брошены бизнес логикой. В самом деле это работает почти без пенальти, как goto, но лишь пока исключение кидается и ловится внутри одной функции — нет нужды разворачивать стек. В других сценариях будет заметная разница.
Лично по мне, если внутри функции появляются какие-то трюки, лучше подумать и сделать рефакторинг. Первое, что приходит на ум — убрать вложенность с помощью product(range(10), range(20)) из itertools. Вынести в отдельную функцию — вполне разумный вариант 3.
Просто запустите тест http://gerg.ca/blog/attachments/try-except-speed.py. Если нет исключений, то try ничего не стоит. Если кидать часто, как в типичных сценариях для control flow, то разница с проверкой кода возврата оказывается значительной.
Проблема возникает из-за разного рода неопределенностей, для моделирования которых по-хорошему есть свои паттерны: значение существует или нет (Optional/MayBe), значение может существовать сейчас или в будущем (Task/Promise), нормальный ход вычислений или альтернативный (Either), есть результат или ошибка (Result) и т.п.
Обработка исключений в python сопоставима с другими языками — бросить почти ни чего не стоит, а перехват обходится дорого. Есть буквально несколько оптимизаций для частных случаев (вроде StopIteration), которые в общем случае погоды не делают. В Java можно отключить захват стека при создании объекта-исключения, что увеличивает перформанс в разы. Но использовать исключения для control flow все равно не стоит.
В outlook на обсуждение обычно приглашается команда, а они внутри уже сами разбираются кто участвует. Кто в to обязательно, кто в cc — опционально. При этом, переписка доступа всем. В тимсах сначала надо найти всех потенциальных учасников для чата поименно (ага, договорившись через почту), а потом ещё решать как шарить на команды обсуждение. Может есть более гуманный способ?
В популярных библиотеках, реализующий такой декоратор, кидают исключение, если метод не был объявлен.
Вообще в примерах кода из оригинальной статьи довольно много ошибок, которые добротно скопированы и в перевод. Может это какой-то вид троллинга?
Теперь представьте, что бизнес ситуация немного поменялась. Решением левой пятки бешеного принтера (ЛПБП), последняя пятница каждого месяца объявляется Днём Анонимности и в этот день, вместо имени, поиск должен использовать девичью фамилию пробабушки.
Геттеры в js удобны тем, что если сделать очепятку в имени, то программа рухнет с исключением. Если использовать свойства, то будет молча пропускать:
const prog = { }
if (!prog.hasBug()) { // упадет с исключением
}
if (!prog.hasBug) { // всегда true
}
Не вижу логики. Если, как указано в статье, основные причины смертей это ошибки водителя, превышение скорости и вождение в нетрезвом виде, то роботы их не отменят, а лишь дополнят новыми рисками на дороге, связанными с несовершенством технологий.
Чтобы организовать обработку списка в один проход не надо торопиться делать странные вещи, отказываясь от filter и map.
Например, нужный эффект можно получить с помошью трансдьюсера (есть хорошее интро по теме: https://www.jeremydaly.com/transducers-supercharge-functional-javascript/ ). В библиотеке lodash, упомянутой в статье, есть похожая фича для filter и map, но с механикой на базе итераторов (chainable methods). В RxJS/IxJS оно так работает по определению.
WinAPI сделано в лучших традициях того времени, в которых несомненно есть рационализм. Но проверку кода возврата легко пропустить и программисту за это ни чего не будет, а с проверками код быстро превращается в месиво из бизнес-логики и control flow. Сигнатуры таких функций не поддаются стандартизации — out параметры могут быть в любом порядке и количестве, а вызовы не compose'ятся между собой. Поскольку out структура не принадлежит вызванной функции, довольно легко накосячить с потокобезопасностью. Собственно, от этого и пытались уйти, изобретая исключения.
Идеоматически в примере 2 кидают StopIteration. Это позволяет отличить такой вот псевдо-goto от прочих исключений, которые могут быть брошены бизнес логикой. В самом деле это работает почти без пенальти, как goto, но лишь пока исключение кидается и ловится внутри одной функции — нет нужды разворачивать стек. В других сценариях будет заметная разница.
Лично по мне, если внутри функции появляются какие-то трюки, лучше подумать и сделать рефакторинг. Первое, что приходит на ум — убрать вложенность с помощью product(range(10), range(20)) из itertools. Вынести в отдельную функцию — вполне разумный вариант 3.
Просто запустите тест http://gerg.ca/blog/attachments/try-except-speed.py. Если нет исключений, то try ничего не стоит. Если кидать часто, как в типичных сценариях для control flow, то разница с проверкой кода возврата оказывается значительной.
Проблема возникает из-за разного рода неопределенностей, для моделирования которых по-хорошему есть свои паттерны: значение существует или нет (Optional/MayBe), значение может существовать сейчас или в будущем (Task/Promise), нормальный ход вычислений или альтернативный (Either), есть результат или ошибка (Result) и т.п.
Обработка исключений в python сопоставима с другими языками — бросить почти ни чего не стоит, а перехват обходится дорого. Есть буквально несколько оптимизаций для частных случаев (вроде StopIteration), которые в общем случае погоды не делают. В Java можно отключить захват стека при создании объекта-исключения, что увеличивает перформанс в разы. Но использовать исключения для control flow все равно не стоит.
В статье goto упомянут 7 раз, и лишь один из них — в коде (да и то в комментарии). Можете объяснить смысл претензии?
В outlook на обсуждение обычно приглашается команда, а они внутри уже сами разбираются кто участвует. Кто в to обязательно, кто в cc — опционально. При этом, переписка доступа всем. В тимсах сначала надо найти всех потенциальных учасников для чата поименно (ага, договорившись через почту), а потом ещё решать как шарить на команды обсуждение. Может есть более гуманный способ?
Вообще в примерах кода из оригинальной статьи довольно много ошибок, которые добротно скопированы и в перевод. Может это какой-то вид троллинга?
Есть-ли способ обнаруживать незакрытые подписки после разрушения компонента, годный для использования в юнит тестах?
Какие способы есть в тимсах для межкомандной коммуникации? Допустим в ситуации когда для решения вопроса требуется участие нескольких команд.
Теперь представьте, что бизнес ситуация немного поменялась. Решением левой пятки бешеного принтера (ЛПБП), последняя пятница каждого месяца объявляется Днём Анонимности и в этот день, вместо имени, поиск должен использовать девичью фамилию пробабушки.
Геттеры в js удобны тем, что если сделать очепятку в имени, то программа рухнет с исключением. Если использовать свойства, то будет молча пропускать:
const prog = { }
if (!prog.hasBug()) { // упадет с исключением
}
if (!prog.hasBug) { // всегда true
}
Напоминает typeclass из хаскелей. Есть адаптация для тайпскрипта fp-ts.
Ценник как полтора кожаных девопса на фултайм.
Redux использует как раз такой подход для реализации модели состояния приложения.
Если сей маленький изъян невидим снаружи, почему это может быть важно? Ловкость рук и никакого мошенничества.
Чтобы организовать обработку списка в один проход не надо торопиться делать странные вещи, отказываясь от filter и map.
Например, нужный эффект можно получить с помошью трансдьюсера (есть хорошее интро по теме:
https://www.jeremydaly.com/transducers-supercharge-functional-javascript/ ). В библиотеке lodash, упомянутой в статье, есть похожая фича для filter и map, но с механикой на базе итераторов (chainable methods). В RxJS/IxJS оно так работает по определению.
Даже в мыслях такого не было.