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

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

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

Программа упадёт совсем :)

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

Много где пустой except - абсолютно валидный кейс.

Давай примеры. Помимо замены break и exit для выхода :)

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

Из какого места пишется сообщение и осуществляется переход на другую ветку, если блок еxcept пуст?

Ну ясно. В общем, я уже написал: запрещать пустые блоки кода в общем случае и говорить джунам, чтобы не ленились. Это вобще не проблема, т.к. такой код на ревью сразу видно. Гораздо сложнее ревьюить простыню, в которой вроде все логично и таких зевков нет, но все равно ощущение быдло-кода не покидает.

Когда я юзал Го эксепшнов небыло. Но вроде говорили что хотят реализовать… Правда долго били копытом. Я 2 недели косяк ловил… Понаделают ерунды

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

PS. Тут есть важный момент - платформы с нормальными системами исключений, когда исключения могут генерироваться только кодом, и с ненормальными в которых исключения могут возникать сами по себе в любом месте, типа питона с KeyboardInterrupt. Понятно что в последних пустой except никак не сделать, так что мы про первые.

Разница с твоей картинкой в том, что оба договорились что у них «6», но один предлагает все равно вести себя так же как «9»(всегда падать независимо от того 6 это или 9), а другой предлагает все таки различать эти ситуации.

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

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

Точно, с паникой попутал.

Да, вывод об ошибке вставляю в except.

Это не всегда нужно знать. Мы Default в таком случае запускаем и, внезапно, это может быть штатный режим работы (особенно когда ты знаешь все эксепшены, которые могут туда прилететь), который даже не требует записи в лог.

Потому что для твоего кейса есть for..in

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

Ещё хорошо бы чтобы оно логи писало при падении и отправлять эти логи девелоперам.
Чтобы в будущем падало меньше.

Плохо договорились, надо договариваться лучше

попробуй доказать что пустой except это плохо

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

питона … пустой except никак не сделать,

Пример в первом ответе :)

Примеров у меня много

Давай пример, когда нужно оставлять без последствий доступ к неинициализированному указателю. Или хоть какой.

Деление на нуль,

Я знаю какие бывают исключения.

доступ по неинициализированному указателю…

Это UB, а не исключение.

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

Это набор слов.

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

а это твоя личная проблема.

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

Давай пример, когда нужно оставлять без последствий доступ к неинициализированному указателю. Или хоть какой.

Я уже сказал что примеров не дам. Доказывай.

Я обычно внутри пустого catch{} пишу какой-нибудь камент. Если там неочевидно почему он пустой, и шоб IDEA не ругалась.

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

Какого рода доказательство тебе нужно?

Давай для начала хоть какое нибудь.

И чем тебя не устраивает пример с неинициализированным экземпляром класса?

Ты ничего не говорил про неинициализированный экземпляр класса. Было про указатель - я повторяю что это UB, а не исключение. Неинициализированный экземпляр класса это тоже UB.

Давай для начала хоть какое нибудь.

Я дал. Тебя оно не устроило. Ты не смог объяснить, чем.

Ты ничего не говорил про неинициализированный экземпляр класса.

Я об этом писал в первом посте. Если экземпляр неинициализирован, получается обращение по неинициализированному указателю, которое ловится как эксепшн.

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

Но вроде говорили что хотят реализовать…

нет

2 недели косяк ловил… Понаделают ерунды

потому что не нужно делать так:

id, err := someRepo.InsertItem(ctx, item)
if err != nil {
    return err
}

нужно аннотировать ошибку

id, err := someRepo.InsertItem(ctx, item)
if err != nil {
    return errors.Wrap(err, "insert item into some repo")
}

такие цепочки

1. Легко читаются, давая представление о месте ошибки. В этом отношении менее удобны чем стектрейсы, но в отличии от них более устойчивы к изменениям кода, т.к. привязаны к бизнес-логике, а не к реализации. При этом могут давать произвольное количество контекста, чего со стектрейсами добиться будет сложно.
2. Такие сообщения об ошибках обычно очень информативны, с их помощью уже даже девопс/админ может в каких-то случаях понять косяк своей настройки и исправить без вмешательства разработчика.

Ну и, разумеется, Go был создан для решения программирования задач в распределённых системах и его система обработки ошибок заточена под них: различные сетевые проблемы в рамках таких систем дело обычное и их обработка является неотъемлемой частью бизнес-логики, не исключительной ситуацией. В этих условиях именно try ... catch становится крайне неудобным инструментом – недавно на себе почувствовал: пишу распределённую базку данных, естественно на C++, ибо критично важна производительность при вычислениях и е–ть сколько костылей приходится вставлять чтобы получать нормальную диагностику, с Go это гораздо проще.

Ну эксепшн очень даже позволяет СВОЙ текст писать.

Я дал.

Ты ничего не дал. И не дашь потому что утверждение ложно и доказать его нельзя.

Я об этом писал в первом посте. Если экземпляр неинициализирован, получается обращение по неинициализированному указателю, которое ловится как эксепшн.

Вот это новости. Это в каком же это языке такое происходит?

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

Ты перешёл на личности, это роспись в некомпетентности и капитуляция. Ок, тогда на будущее вот тебе примеры из первого попавшегося проекта:

• строится график от каких-то данных по сложной формуле. Мне наплевать что там внутри случится - Null во входных данных, отсутствие ключа во входных данных, деление на 0, корень из -1, arctan(100500), картинка с пони там где ожидался float… Мне нужно просто пропустить точку которую нельзя посчитать, и правильным решением будет только и исключительно пустой except.

• читаются какие-то данные которые не жалко потерять. Например, какой-то кэш, или время последней проверки на наличие новой версии. Мне также абсолютно насрать что там случилось если я не могу его прочитать - файла нет, файл пустой, нет прав, полностью изменился формат, вместо времени проверки там лежит полная дискография группы «Время срать»… Я просто проигнорирую любую ошибку, и может быть нирисую какой-нибудь варнинг при неудаче записи этого кэша/значения.

Ты перешёл на личности

…и хотя бы так убедил тебя ответить на вопрос :)

строится график … Мне наплевать что там

Garbage in, garbage out. Совсем забыл, что бывают программисты, которые обслуживают программы, занятые преобразованием мусора в мусор. И валидные точки среди этого мусора тоже никому не нужны, иначе мусорные точки хоть как-то помечались бы. Мои соболезнования.

читаются какие-то данные которые не жалко потерять. Например, какой-то кэш

Если чтение кэша приводит к эксепшену, почему должно считаться, что кэш успешно прочитался?

может быть нирисую какой-нибудь варнинг при неудаче записи этого кэша/значения

А как ты поймёшь, что пишешь мусор? Или результат тоже не имеет значения?

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

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

Плюс.

Мне наплевать
Мне также абсолютно насрать

Потом и удивляемся, какого фига веб страничка на которой 1к полезной информации весит 300м.

…и хотя бы так убедил тебя ответить на вопрос :)

Нет, ты не воспользовался возможностью не сесть в лужу и потерял уважение как собеседник.

Garbage in, garbage out. Совсем забыл, что бывают программисты, которые обслуживают программы, занятые преобразованием мусора в мусор. И валидные точки среди этого мусора тоже никому не нужны, иначе мусорные точки хоть как-то помечались бы. Мои соболезнования.

Мои соболезнования тем кто забыл что живёт не в идеальном манямирке. Данные с мусором - это порождение объективной реальности, а то что мусор на каком-то этапе отфильтровывается - это как раз процесс обратный преобразованию «в мусор», так что мимо. А то, как такие точки обрабатываются - дело уже другого кода, точка у которой не посчитали значение может никуда дальше не ехать, а может ехать как «не посчитано значения», того факта что в except для неё __нужно__ ничего не делать это не меняет.

Если чтение кэша приводит к эксепшену, почему должно считаться, что кэш успешно прочитался?

Никто и не считает что он успешно прочитался. Он просто остаётся пустым.

А как ты поймёшь, что пишешь мусор? Или результат тоже не имеет значения?

О чём ты, болезный? Я не пишу мусор, я пишу детерминированные данные.

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

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

Я об этом писал в первом посте. Если экземпляр неинициализирован, получается обращение по неинициализированному указателю, которое ловится как эксепшн.

Читал новость и вспомнил тебя

Яндекс, TikTok, Авито и другие приложения не запускаются на iOS по всему миру

На стороне Facebook SDK произошел масштабный сбой, из-за которого перестали работать многие популярные приложений на iOS. Facebook SDK используется во множестве приложений для аналитики, таргетинга и авторизации пользователей. Сбой затронул пользователей TikTok, Spotify, Pinterest, Tinder, Viber, некоторые сервисы Яндекса и множество сервисов других компаний во всем мире.

Я приводил как раз такой пример. API возвращает неожиданный ответ, прога падает. Это предсказуемо и тупо.

Спасибо… Дотипизировались