Ну в Яндекс.Еда(Доставка) Есть положительного много, например это почти единственная возможность для многих инвалидов заработать нормальные деньги, встречал разных инвалидов. Им респект и уважуха за это, низкий поклон и всяческие дифирамбы. Второй положительный момент, конечно же люди без опыта, но такие могут найти и менее пыльную работу. Третий положительный момент, особенно не для Москвы, это романтика, и чувство, что ты делаешь добро людям. Это так мило когда ребенок бежит к доставщику с распростертыми руками и визгами радости. Доставщик катается, а не сидит в душном офисе. Но романтика это не для денег, скорее для подработки, но и за это спасибо.
Но есть и минусы, например необоснованные штрафы и списания баллов приоритета. Так например Яндекс нарушает свой же договор, где говорится, что если груз превышает массу или габариты, то можно отказаться от доставки, но не указывает, что доставщик будет наказан за это списаниями баллов. Т. е. явное нарушение Закона Яндексом. Такая же ситуация с невыполнимыми заказами, когда точка получения заказа закрыта, и доставщик может только отменить заказ и.. быть наказан списанием баллов приоритета. Т. е. тут тоже прямое нарушение Закона. Так же странная система распределения, которая может начать кидать заказ через весь город, район, выполнить на 80 руб, а потом закинуть обратно и так несколько раз, отказаться нельзя, спишут баллы.
"Если программа получила исключение, что база данных недоступна по сети, то она должна остановиться, а не продолжать алгоритм с пустыми данными."
Пример хорош, но с таким же успехом я могу привести пример ожидания появления файла в файловой системе, вы каждый раз будете дергать глобальный обработчик или всë же будете действовать по ситуации и ловить исключения там где это логично, в функции проверки наличия файла файловой системы, не доводя до глобального обработчика? Как раз тут ситуация как не остановить программу, а заставить еë работать и ждать результата.
"Правильно уверены, и применять его не надо, если есть возможность сделать по-другому."
Совсем неверный постулат, если инструмент работает лучше чем другие варианты, то лучше применить этот инструмент. И хороший мастер должен знать где и когда лучше применять инструмент. Не надо молотком забивать шурупы, а отверткой закручивать гвозди. Goto тоже можно и нужно использовать, а что бы знать когда и где нужно не хейтить, а обучать, разъяснить. Вы предлагаете мыслить шаблонами, как возможно вас приучили это делать, не спорю это тоже результативно.
"Ловить их, тем более по специфичному типу, и продолжать выполнение в большинстве случаев не надо. Исключительная ситуация должна останавливать программу, потому она и исключительная."
В этом вся проблема шаблонов, вы почему-то твердо уверовали, в то, что только ваше применение это правильно, но в документации Java отлично показано, что можно использовать в том числе и fast-return. И хочу вас просветить, Исключения придумали не для того что бы останавливать программу, а именно для того, что бы по возможности не останавливать еë.
Мои придирки были обращены к оператору goto, который является всего лишь инструментом, но который необоснованно хейтят и приплетают ситуацию с ним в прошлом к другим проблемам, вызывая негатив и отторжение к данному инструменту. Изначально кампания была по ограничению и правильному использованию GOTO, которая переросла в довольно кривобокую картину, когда молодые разработчики уверены, что GOTO это плохо и боятся применять его или даже не знают о его возможностях. Это не то к чему надо стремиться и статья вызывает критику в том числе и кликбейтным заголовком и необоснованным принижением инструмента разработки.
Я с вами полностью согласен, что всë программирование это ИМХО, но при этом вы высказывкетесь в довольно категоричной форме:"Я написал как надо...", это читается, что всë остальное не надо?) Понимаю что это может быть оборот речи у вас, но всë же... Вы и выше утверждаете, что только глобальный обработчик это правильно. Но с вами несогласны именно разработчики языков, о которых я говорил, или вы участвуете в разработках языков Java и т. д. ? Думаю я непонятно выразился... Увлекаться глубиной fast-return согласен не всегда хорошо, но и прям пренебрегать как вы данным инструментом, как вы советуете тоже сомнительно.
Но если почитать заголовок и хейт на goto то создаётся впечатление, что goto это зло.
И опять же это не из-за C, а из-за процессора, Goto это jmp. Для адептов антиГото, можно было сделать вместо Goto очищающую функцию, в которую передавали бы параметры очистки и т. д. Но нет, используют не потому что ограничение C, а потому что вызов функции медленнее в разы, а тут раз и вышел если всë хорошо.
Пример интересный, но goto и throw это инструмент, а не модная штука. Просто надо руководствоваться здравым смыслом. Проекто с ужасными result которые без слез не раскрутишь тоже не мало.
Замечательно и где противоречия с моими высказываниям? И на сколько NotFound это нормально? Давайте не будете врать ни мне ни себе. Это ошибка поведения программы, возврат значения которое не является успешным. 403 это ОШИБКА. Это уже не Normal Flow. И тут вопрос как обрабатывать лучше и удобнее. Ничто не мешает, в том числе и ваша ссылка на MS, использовать исключения и консолидированную обработку на уровнях ниже, можно даже прописать каждому исключению свой класс, что будет смотреться и обрабатываться удобнее. Но конечно можно промудрить по классике с Result. Сколько людей, столько и мнений?
Тут ситуация такая вырисовывается:
Представим: Брюки это Исключения, Килт это Result
Автор: "Если пойти в туалет и не снять Брюки, то может произойти казус, а вот если использовать Килт, то это минимизирует ущерб"
Комменты:" Да точно, вы правы Брюки надо расстегивать и да Килт это вроде круто! "
Автор: " Если расстегнуть ширинку на Брюках, но при этом стоять против ветра, то может произойти казус, а вот при использовании Килта такие проблемы минимизированы. "
Комменты: "О да, делать это против ветра это конечно не разумно, Килт выглядит очень удобно! "
Автор: " ну вот используйте Килт чаще чем Брюки! "
Комменты:"Стопэ, Килт конечно это круто, но мы привыкли использовать Брюки, и да мы не забываем их расстегивать и стараемся контролировать направление ветра, поэтому извини дружище, но мы уже в Брюках походим. "
Расскажите нам, что плохого в Goto, что бы дальнейшие ваши претензии были обоснованы. Просто такое ощущение, что у большинства людей поливающих грязью Goto нет понимания для чего и где он используется.
Во вторых если вы почитаете про исключения, наконец от разработчиков, то обнаружите, что поведение исключений не сильно отличается от простых return, просто заданных неявно. И если вы используете return, то вы попадаете на то, что вы вынуждены разворачивать всегда всю цепочку вызовов, даже если на верху что-то пошло не так и выполнять данный набор команд(функций и т. д.) не имеет смысла и нужно перейти к другим. Именно это делают исключения, убирая ненужные return для вложенности, а сразу переходя к коду обработчку(ловушке).
И да, просто возвращать положительный результат это не очень хорошая практика, но это нигде не запрещено явно и руководствуется только здравым смыслом, как и с оператором Goto, всë остальное это ваше ИМХО.
Спасибо, очень интересная статья, но она о сферическом коне в вакууме и приводить еë как аргумент как минимум не уместно, т. к. в итоге мы видим, что на самом деле эффективность в пределах разумного, а писать критические приложения где сборщик мусора может в любую секунду обнулить все оптимизации, такое себе) Опять же хочу обратить внимание, что данный оппус был создан пользователем Хабр, что не является истиной в последней инстанции, а в свете погони авторов за рейтингами вообще критически отношусь ко всем публикациям на Хабр, к чему и призываю всех людей. А то потом эти необоснованные статьи попадают в индексацию и тем самым влияют на неокрепшие мозги других пользователей и они начинают следовать призывам и утверждениям в данных статьях. Ещë раз, лучше придерживаться рекомендациям от производителей и разработчиков языков, а там черным по белому написано "Используйте исключения, они эффективны для большинства ваших задач"
Мне кажется человек с такими утверждениями не может считаться хорошим программистом. Мало того, что утверждение про goto ложно и вытекает из некоторых нежелательных моментов при его использовании, но автор этого высказывания подчеркивал, что именно избыточное и необдуманное использование goto может привести к проблемам. Автору посоветую глянуть код BSD или Linux, для просвещения. Тем более после компиляции C кода Goto преобразуется в JMP, что более эффективно чем всë остальное, но вы про эффективность не слышали?
Теперь пройдемся про throw, оно придумано и рекомендовано к использованию в любых ситуациях, что прямо прописано в документации Java, и там же разобрано как с ним работать, думаю вы не осилили это, раз появилась очередная холиварная статья. Так же в документации и курсах от Microsoft так же четкая рекомендация использовать throw. Если они для вас не авторитеты, то даже не знаю как характеризовать эту статью не прибегая к грубым эпитетам.
Почему не любили throw раньше? На слабых компьютерах и ограниченном объеме в реализации этого на C++ получался огромный оверхед, который съедал относительно много памяти и процессорного времени. Отсюда пошли статейки, что лучше не использовать throw, а только в критических местах. В java и прочих интерпретаторах или JIT языках такой проблемы нет, а сейчас и с памятью и мощностью процессоров проблем нет, так что не надо выдумывать проблемы где их нет, а просто научитесь писать правильный код.
Ну в Яндекс.Еда(Доставка) Есть положительного много, например это почти единственная возможность для многих инвалидов заработать нормальные деньги, встречал разных инвалидов. Им респект и уважуха за это, низкий поклон и всяческие дифирамбы. Второй положительный момент, конечно же люди без опыта, но такие могут найти и менее пыльную работу. Третий положительный момент, особенно не для Москвы, это романтика, и чувство, что ты делаешь добро людям. Это так мило когда ребенок бежит к доставщику с распростертыми руками и визгами радости. Доставщик катается, а не сидит в душном офисе. Но романтика это не для денег, скорее для подработки, но и за это спасибо.
Но есть и минусы, например необоснованные штрафы и списания баллов приоритета. Так например Яндекс нарушает свой же договор, где говорится, что если груз превышает массу или габариты, то можно отказаться от доставки, но не указывает, что доставщик будет наказан за это списаниями баллов. Т. е. явное нарушение Закона Яндексом. Такая же ситуация с невыполнимыми заказами, когда точка получения заказа закрыта, и доставщик может только отменить заказ и.. быть наказан списанием баллов приоритета. Т. е. тут тоже прямое нарушение Закона. Так же странная система распределения, которая может начать кидать заказ через весь город, район, выполнить на 80 руб, а потом закинуть обратно и так несколько раз, отказаться нельзя, спишут баллы.
ну да вместо микроскопа использую смартфон, не всегда удобно, но бюджетно
Я тоже пишу на личном опыте. Спасибо.
"Если программа получила исключение, что база данных недоступна по сети, то она должна остановиться, а не продолжать алгоритм с пустыми данными."
Пример хорош, но с таким же успехом я могу привести пример ожидания появления файла в файловой системе, вы каждый раз будете дергать глобальный обработчик или всë же будете действовать по ситуации и ловить исключения там где это логично, в функции проверки наличия файла файловой системы, не доводя до глобального обработчика? Как раз тут ситуация как не остановить программу, а заставить еë работать и ждать результата.
"Правильно уверены, и применять его не надо, если есть возможность сделать по-другому."
Совсем неверный постулат, если инструмент работает лучше чем другие варианты, то лучше применить этот инструмент. И хороший мастер должен знать где и когда лучше применять инструмент. Не надо молотком забивать шурупы, а отверткой закручивать гвозди. Goto тоже можно и нужно использовать, а что бы знать когда и где нужно не хейтить, а обучать, разъяснить. Вы предлагаете мыслить шаблонами, как возможно вас приучили это делать, не спорю это тоже результативно.
"Ловить их, тем более по специфичному типу, и продолжать выполнение в большинстве случаев не надо. Исключительная ситуация должна останавливать программу, потому она и исключительная."
В этом вся проблема шаблонов, вы почему-то твердо уверовали, в то, что только ваше применение это правильно, но в документации Java отлично показано, что можно использовать в том числе и fast-return. И хочу вас просветить, Исключения придумали не для того что бы останавливать программу, а именно для того, что бы по возможности не останавливать еë.
Мои придирки были обращены к оператору goto, который является всего лишь инструментом, но который необоснованно хейтят и приплетают ситуацию с ним в прошлом к другим проблемам, вызывая негатив и отторжение к данному инструменту. Изначально кампания была по ограничению и правильному использованию GOTO, которая переросла в довольно кривобокую картину, когда молодые разработчики уверены, что GOTO это плохо и боятся применять его или даже не знают о его возможностях. Это не то к чему надо стремиться и статья вызывает критику в том числе и кликбейтным заголовком и необоснованным принижением инструмента разработки.
Я с вами полностью согласен, что всë программирование это ИМХО, но при этом вы высказывкетесь в довольно категоричной форме:"Я написал как надо...", это читается, что всë остальное не надо?) Понимаю что это может быть оборот речи у вас, но всë же... Вы и выше утверждаете, что только глобальный обработчик это правильно. Но с вами несогласны именно разработчики языков, о которых я говорил, или вы участвуете в разработках языков Java и т. д. ? Думаю я непонятно выразился... Увлекаться глубиной fast-return согласен не всегда хорошо, но и прям пренебрегать как вы данным инструментом, как вы советуете тоже сомнительно.
Но если почитать заголовок и хейт на goto то создаётся впечатление, что goto это зло.
И опять же это не из-за C, а из-за процессора, Goto это jmp. Для адептов антиГото, можно было сделать вместо Goto очищающую функцию, в которую передавали бы параметры очистки и т. д. Но нет, используют не потому что ограничение C, а потому что вызов функции медленнее в разы, а тут раз и вышел если всë хорошо.
Пример интересный, но goto и throw это инструмент, а не модная штука. Просто надо руководствоваться здравым смыслом. Проекто с ужасными result которые без слез не раскрутишь тоже не мало.
Замечательно и где противоречия с моими высказываниям? И на сколько NotFound это нормально? Давайте не будете врать ни мне ни себе. Это ошибка поведения программы, возврат значения которое не является успешным. 403 это ОШИБКА. Это уже не Normal Flow. И тут вопрос как обрабатывать лучше и удобнее. Ничто не мешает, в том числе и ваша ссылка на MS, использовать исключения и консолидированную обработку на уровнях ниже, можно даже прописать каждому исключению свой класс, что будет смотреться и обрабатываться удобнее. Но конечно можно промудрить по классике с Result. Сколько людей, столько и мнений?
Тут ситуация такая вырисовывается:
Представим: Брюки это Исключения, Килт это Result
Автор: "Если пойти в туалет и не снять Брюки, то может произойти казус, а вот если использовать Килт, то это минимизирует ущерб"
Комменты:" Да точно, вы правы Брюки надо расстегивать и да Килт это вроде круто! "
Автор: " Если расстегнуть ширинку на Брюках, но при этом стоять против ветра, то может произойти казус, а вот при использовании Килта такие проблемы минимизированы. "
Комменты: "О да, делать это против ветра это конечно не разумно, Килт выглядит очень удобно! "
Автор: " ну вот используйте Килт чаще чем Брюки! "
Комменты:"Стопэ, Килт конечно это круто, но мы привыкли использовать Брюки, и да мы не забываем их расстегивать и стараемся контролировать направление ветра, поэтому извини дружище, но мы уже в Брюках походим. "
Расскажите нам, что плохого в Goto, что бы дальнейшие ваши претензии были обоснованы. Просто такое ощущение, что у большинства людей поливающих грязью Goto нет понимания для чего и где он используется.
Во вторых если вы почитаете про исключения, наконец от разработчиков, то обнаружите, что поведение исключений не сильно отличается от простых return, просто заданных неявно. И если вы используете return, то вы попадаете на то, что вы вынуждены разворачивать всегда всю цепочку вызовов, даже если на верху что-то пошло не так и выполнять данный набор команд(функций и т. д.) не имеет смысла и нужно перейти к другим. Именно это делают исключения, убирая ненужные return для вложенности, а сразу переходя к коду обработчку(ловушке).
И да, просто возвращать положительный результат это не очень хорошая практика, но это нигде не запрещено явно и руководствуется только здравым смыслом, как и с оператором Goto, всë остальное это ваше ИМХО.
Спасибо, очень интересная статья, но она о сферическом коне в вакууме и приводить еë как аргумент как минимум не уместно, т. к. в итоге мы видим, что на самом деле эффективность в пределах разумного, а писать критические приложения где сборщик мусора может в любую секунду обнулить все оптимизации, такое себе) Опять же хочу обратить внимание, что данный оппус был создан пользователем Хабр, что не является истиной в последней инстанции, а в свете погони авторов за рейтингами вообще критически отношусь ко всем публикациям на Хабр, к чему и призываю всех людей. А то потом эти необоснованные статьи попадают в индексацию и тем самым влияют на неокрепшие мозги других пользователей и они начинают следовать призывам и утверждениям в данных статьях. Ещë раз, лучше придерживаться рекомендациям от производителей и разработчиков языков, а там черным по белому написано "Используйте исключения, они эффективны для большинства ваших задач"
Мне кажется человек с такими утверждениями не может считаться хорошим программистом. Мало того, что утверждение про goto ложно и вытекает из некоторых нежелательных моментов при его использовании, но автор этого высказывания подчеркивал, что именно избыточное и необдуманное использование goto может привести к проблемам. Автору посоветую глянуть код BSD или Linux, для просвещения. Тем более после компиляции C кода Goto преобразуется в JMP, что более эффективно чем всë остальное, но вы про эффективность не слышали?
Теперь пройдемся про throw, оно придумано и рекомендовано к использованию в любых ситуациях, что прямо прописано в документации Java, и там же разобрано как с ним работать, думаю вы не осилили это, раз появилась очередная холиварная статья. Так же в документации и курсах от Microsoft так же четкая рекомендация использовать throw. Если они для вас не авторитеты, то даже не знаю как характеризовать эту статью не прибегая к грубым эпитетам.
Почему не любили throw раньше? На слабых компьютерах и ограниченном объеме в реализации этого на C++ получался огромный оверхед, который съедал относительно много памяти и процессорного времени. Отсюда пошли статейки, что лучше не использовать throw, а только в критических местах. В java и прочих интерпретаторах или JIT языках такой проблемы нет, а сейчас и с памятью и мощностью процессоров проблем нет, так что не надо выдумывать проблемы где их нет, а просто научитесь писать правильный код.