Это какая-то локальная проблема в Паскалях?

Ничего.

Это способ игнорировать проверяемое исключение.

переводят в сеньоры и тимлиды - ведь такие люди очень полезны для бизнеса.

Способ жидко обделаться и даже этого не понять.

Просят написать пояснительный комментарий.

Это какая-то локальная проблема в Паскалях?

Нет, это общая проблема языков, где есть try-except и ленивые кодеры :) Хотя приведённый фрагмент был написан по невнимательности.

Ну мне приходилось городить try..except в python. Только это требовалось для выполнения каких-то банальных вещей, где язык тебе вставлял палки в колёса. Быстрее решение чем пустой except, просто не придумать, как по мне.

Я не пишу больших проектов, разве что-то больше лабы.

Ситуативно. Иногда нам пофигу какой именно эксепшн прилетит и тогда, мы либо вообще другую ветку кода запустим, либо напишем общее сообщение, что юзер дурак и пытается сделать какую-то фигню.

Ну и это, ты для начала все системные эксепшены своего ЯП перечисли (а потом со стандартом сравни и посчитай сколько ты не вспомнил) и сразу всё поймешь.

либо напишем общее сообщение, что юзер дурак и пытается сделать какую-то фигню.

Был один такой, который в тесте прямо так и выводил «Сам дурак!», если тест фейлился.

У нас сразу увольняют. Только не их, а тупорылых догматиков которые услышали от кого-то что А - плохо, и с тех пор это повторяют как попугаи не включая голову. Много где пустой except - абсолютно валидный кейс.

Разве это не оверхэд?

Обычно это когда на любой эксепт требуется дефолтное поведение. Часто можно простыми проверками обойтись.

Иногда нам пофигу какой именно эксепшн прилетит и тогда

не иногда, а очень часто
в оракле самый частый обработчик исключений - это

begin
  ... тут код
exception
  when others then null;  -- а тут пустой обработчик на все виды исключений
end;

Ловился случай, когда b не инициализирован.

Чего?

Что будет если убрать обработку исключений вообще?

А что там должно быть по-твоему? Я обычно так делаю, чтобы код выполнялся после некритичной ошибки. Это как soft assert. Только вставляю вывод в консоль для дебага.

Совершенно нормальная практика оборачивать в пустой except вызов внешнего обработчика события. Потому что неизвестно, что там за говнокод наляпан уровнем выше, пусть его автор разбирается, а моему классу нужно продолжать работу без разрушения всего стека вызовов.

В гитхуках ищешь строку где только эксепт и не даешь пушить. ВСЕ

тогда except # noqa

Да как-то сам такое видел. Лютый кошмар потом…

Причём даже ексепшены с пустым обработчиком и не раз на одну инструкцию var=arr[i]; Ну мало, что выходит за пределы массива. И без системно…

Будет Go

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

Смотри у нас на одной из прошлых работ был спор с Девопсом. Я говорил ПРОГА в непредсказуемой ситуации должна упасть. А он говорил, нет надо продолжить работу написав в лог.

Вот представь: Банковское ПО. Ошибка в расчете процента за услугу. Ты шлешь миллион. Клиент должен получить миллион - процент. А он получает миллион. Как думаешь начальство обрадуется если это обнаружится через год? ВСЕГДА ты должен указать КАКИЕ ты ловишь ошибки. Да ты не обработаешь нехватку памяти и нехватку места на диске - падай.

Вот представь: Банковское ПО…

Это ты сейчас придумал. В посте ТС ничего нет про деньги. Может там картинка на монитор выводится, и от того, что b неинициализирована, будет один черный пиксель.

Вы оба правы по-своему. Когда прога работает через API, может быть куча вариантов, когда приходит нестандартный ответ. Обработка этого должна быть, но бывает, что API плохо документирован или вообще чужой. И что клиенту блочить весь функционал, теряя бабло, пока там чьи-то индусы в носу будут ковырять? На критичные фичи, особенно с баблом, должны быть тесты, минимум юнит, по хорошему e2e.

У меня в виме try стоит на установку темы, если темы нет оно не ругается доставучим окошком. Вернее стояло, сейчас убрал ибо там сломали Eблаблячётотам код ошибки и ругалось уже доставучим окошком что нет такого кода ошибки :D

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

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

PS: выдохнул, всё таки пятница утро и опять кучи говна разгребать:)

Если подобное написать в цикле, то программу даже не убьёшь по ctrl+c т.к. оно будет глотать KeyboardInterrupt.

Если бюджет как часто бывает у нас сейчас со всякими гос организациями

это так везде, и у коммерсов тоже

В общем добро пожаловать в AGILE и прочие методологии.

Agile то тут вобщем не причем. Такой код, как у ТС, по-хорошему, зарубится на этапе ревью как содержащий пустой блок. Это даже можно в кодинг стайл прописать, типа «пустые блоки не разрешаются, за исключением тех случаев, когда без них невозможно, например, определение конструктора с инициализаторами». Самое сложное - проверить, что эксепшн может быть кинут из того или иного вызова. Не знаю, как там в компиляторе Паскаля с этим обстоит, но тут кодер уже сделал за ревьюера всю работу, указав, что таки эксепшн кидается. Не ну реально, если ревью пропускает такой код без комментариев и обеспокоенностей, то нечего на Agile пенять, коль программисты дебилы.

Качество ревью зависит от бюджета проекта и как следствие от тех, кто назначен делать ревью и тех, кто пишет код. Вроде бы как AGILE и не причём, но AGILE появился как раз для ускорения процесса разработки с точки зрения покупателя. Ускорить же процесс разработки нельзя, попутно не поломав ничего. Всегда приходится чем-то жертвовать. Если в идеале, предполагается, что каждые там неделю-две-месяц должен быть прирост фич и они должны работать, как планировалось, то в реальности часто заказчики хотят это ещё и почти даром, и быстрее ну и как следствие приходится жертвовать много чем. Доходит до того, что тот кто делает ревью может быть узбеком, а тот кто пишет код, вообще марсианен. При том про узбека я не пошутил. И это не камень в огород узбеков, в данном случае я это упомянул потому, что они иногда ещё дешевле, чем русские из какой-нибудь жопы.

Но еще раз, аджайл тут не причем. Нет такого пункта в аджайл «экономить любой ценой», и даже, ЕМНИП не утверждается, что суммарные затраты на проект будут ниже суммарных затрат при традиционной методологии.

Что у вас делают с людьми, которые оставляют пустые except?

Эх, был бы тут Делериум, он бы рассказал.

Фу так делать

Плохому программисту язык палки в колёса вставляет, ага

Он просто не хотел делать свою работу.
Поднять сервис после падения — его работа.

https://sun9-65.userapi.com/c841226/v841226541/52e84/ojx2SyarcRI.jpg

Нет.
Не бывает ситуаций, в которых оба «правы по-своему».

Ctrl + Z
kill -9 program

Ну да, конечно. Я не отрицаю что я не профессиональный программер, но когда при переполнении итератора в while..do начинаються IndexError-ы, и решить это можно только try..except, то некуда деваться. Почему бы сразу не пропускать цикл, а не выводить мне ошибку и аварийно завершать программу?! Это самое банальное что я вспомнил когда писал.

Пихают экскептион в дупло

Да ну, я предпочитаю шнур выдернуть, заодно из вима выходит.

Будет Go

Она ж там есть вроде.

Да ну, я предпочитаю шнур выдернуть, заодно из вима выходит.

Ну вот и выросло поколение хипстеров. А деды выходили по кнопке reset на системнике.

Нету и не будет. Если ты про panic/recover, то это не exceptions.

Совершенно нормальная практика оборачивать в пустой except вызов внешнего обработчика события. Потому что неизвестно, что там за говнокод наляпан уровнем выше, пусть его автор разбирается, а моему классу нужно продолжать работу без разрушения всего стека вызовов.

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

Хорошо, тогда прав девопс. Потому что должны быть тесты, а программа не должна падать от изменения погоды на Марсе.

нет, это не нормально: в продакшене в таких случаях надо писать ворнинг

несмотря на вышенаписанное, иногда сама используемая либа написана криво и exception кидается когда он нахрен не упёрся: например, так делает substr() в STL

в таких случаях, пустой обработчик exception писать можно и нужно

спор с Девопсом

Поднять сервис после падения — его работа.

Более того, основной принцип девопс: не чтобы не падало, а чтобы быстро поднималось :)

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

А автор уровнем выше уровнем выше думает так же, и оборачивает в пустой except сообщения об ошибках от твоего кода. А пользователь видит как у классика: «А включаешь — не работает.»

Хотя нет. Ты ведь даже об ошибках не сообщаешь :)

А что там должно быть по-твоему? Я обычно так делаю, чтобы код выполнялся после некритичной ошибки. Это как soft assert. Только вставляю вывод в консоль для дебага.

А куда вставляешь этот вывод в консоль? В except? Или оставляешь except пустым, а в консоль пишешь всегда? В примере except пустой :)