golang - не хочу возвращать err, хочу паниковать!

Ты намекаешь, что там всё как-то ужасно?

Нет я намекаю, что там все хорошо... Это недостаток

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

Мир не идеален, но это не значит, что уже не имеет смысла к этому стремиться.

а для питона я не видел ничего подобного.

Сравнение тёплого с мягким.

Оснавная причина, по которй используется проверка ошибок - это скорость.

Нет.

Да

В нормальной кодовой базе и утечек нет. В нормальном мире вообще всё хорошо. Только это не наш случай.

Нет, вы путаете нормальный мир с идеальным. В нормальном мире люди допускают ошибки. Но вот делать throw int в нормальной кодовой базе не будут. Индивиды, вроде ТС-а, которые везде рассуют своих тараканов есть, конечно, но от них нормальных кодовых баз не остается.

С чего бы это?

Потому что их там не будет.

На самом деле просто не надо тратить своё мнение на чтение подобных религиозных трудов.

Кстати в Go2 обещают подвезти check.

fl, err := os.Open("path")
if err != nil {
    return err
}

превартится в

fl check := os.Open("path")

if err != nil {
   return [replies], err
}

Оснавная причина, по которй используется проверка ошибок - это скорость.

Нет.

Да

Нет и ещё раз нет.

человека, который пилил собственный ЯП

Если бы таких людей не было бы, то не было бы новых языков.

Горазо быстрее проверить ошибку, или, например, число перед делением, чем обрабатывать исключение

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

Соответственно, в разных задачах будет эффективны разные подходы.

В нормальной кодовой базе и утечек нет

Некорректное сравнение. Утечку тяжело обнаружить на том же ревью кода, а вот выброс странного исключения - легко.

Но вот делать throw int в нормальной кодовой базе не будут.

На днях была новость об очередной уязвимости в ядре. Угадайте в чем была проблема? Оказывается кто-то, в хорошей кодовой базе, забыл задать NULL переменной. Чудеса.

выброс странного исключения - легко

С чего бы это? Если оно бросается раз в 100 лет - нет. И тесты тут не помогут.

На днях была новость об очередной уязвимости в ядре. Угадайте в чем была проблема? Оказывается кто-то, в хорошей кодовой базе, забыл задать NULL переменной. Чудеса.

Ядро линукс — хорошая кодовая база? Окай…

test::black_box

Если вы отождествляете GNU-тый диалект C c С++, а забытое присваивание NULL с throw int, то у меня для вас плохие новости...

А нет, хорошие: для вас уже сделали Go и Rust. На чем-либо другом вы не сможете программировать, будет слишком сложно и непонятно.

Ну да

~~@~~

Получить скорость (для Go) лучшую чем проверка мне не удалось.

https://play.golang.org/p/kHUC0y7-iRa

Это скорее вопрос написания кода без заморочек. Т.к. на на ловлю и обёртку всех ошибок уходит ощутимое количество времени. Хотя если просто 'return err', то вроде не особо трудно. Сниппеты там и всё такое.

Думаю задержка recovera сильно увеличится, если recover расположен на дне стопки вызовов, а паника далеко сверху. Что собствено и является единственным возможным вариантом сокартить количество писанины касательно ошибок.

Это был намёк.

Ох, простите, вот корректный пример.

https://play.golang.org/p/Hj-8aam0N77

Почти одинаково для хорошео случая, когда нет ошибок. 100-200ns разница для 110'000ns общего времени.

Обернув всё в rustc_test::black_box, получил:

test errors ... bench:          56 ns/iter (+/- 1)
test panics ... bench:       9,758 ns/iter (+/- 335)

То есть тоже самое.

Да любой дудосер обрадуется подобным новшевствам

Да, это тоже аргумент.

С чего бы это? Если оно бросается раз в 100 лет - нет. И тесты тут не помогут.

А ревью кода поможет.

Вообще перестал понимать я что-то. Почему хороший профайлер - это недостаток?

Я имел в виду отделить деструкторы (содержание defer) от самой инфраструктуры, т.е. от собственно defer.

Конечно, я клал с прибором только на чужие предрассудки, прежде всего, на «указания от гуру о том, как надо делать». Свои-то тараканы могли порезвиться. А чем плохо?

Спорить не буду, т.к. ещё жива отдельная тема именно про это: питонизируем си, js и иже с ними

Почему ЕДИНСТВЕННЫЙ профайлер недостаток?

Ревью чужого кода? Ну тут я об этом и пишу.

Какая связь между «хочу много денег» и «компиляцию в машкод»? Почему тебя это волнует? Ты считаешь деньги за бинарь кошернее? Мудро конечно взять и по религиозным причинам урезать себе выбор до 1 (одной) технологии, а потом жаловаться на религиозное мышление окружающих.

Если оно бросается раз в 100 лет - нет. И тесты тут не помогут.

Просто забей. Ты не доживешь до этого случая, а если доживешь, то исправишь. Вот все больше убеждаюсь, что у рустеров пунктик насчет «компилятор должен все-все предусмотреть, иначе боюсь-боюсь». Баги все равно будут, как бы вы соломку не стелили.

Да да, пусть хромает дальше в не консистентном состоянии. Или, изящно выходит при ошибке на 20ом уровне вложенности. То-то при разыменовании нулевого указателя errno взводится вместо сегфолта, не дураки ведь делали.

Баги все равно будут, как бы вы соломку не стелили.

Это не оправдание для того, чтобы использовать настолько откровенно ущербный язык, как C.

~~@~~

И какой в этом толк?

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

Как узнать, что она вызывает внутри и что может вылететь наружу?

При сборке это видно компилятору, в с++ же как-то вывод типов сделали.

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

Плюсую. Нужно.

Что мешает использовать фаззин для питона?

Тем что его не существует?

Почему бы и нет?

Почему бы и нет?

Фаззить питон тем, что не существует?

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

Я так понимаю, что если у вас есть некий метод void f() throws * {...}, то сказанное вами относится не к нему, а к методам, в которых f() вызывается. Скажем вот здесь:

void g() {
  f();
  ...
}

При том, что g() не знает, что может вылетать из f(), единственный вариант — это сделать в g() catch(Exception).

Ну так все тоже самое вы уже можете получить используя throws Exception.

При сборке это видно компилятору, в с++ же как-то вывод типов сделали.

Тогда вам придется ограничить контексты, в которых throws * может использоваться. В частности:

- запретить throws * для public-методов public-классов. В противном случае вам кто-то отдает jar с каким-то кодом версии 1.0.0, и там один набор исключений вылетает. Потом вы обновляетесь до версии 1.2.0 этого jar-а и сталкиваетесь уже с другим набором. Соответственно, вы начинаете зависеть от деталей реализации чужого кода, что есть очень плохо;

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

При этом ваш throws * не решает главную проблему RazrFalcon-а: не показывает, какие ошибки могут вылететь из метода.

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

запретить throws * для public-методов public-классов.

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

запретить throws * у методов интерфейсов

правда, видимо по этой причине checked exceptions сделаны так как сделаны.

видимо по этой причине checked exceptions сделаны так как сделаны.

Мой опыт говорит о том, что checked exceptions — это отличная реализация красивой, в теории, идеи.

Но проблема в том, что теория и практика оказались разными вещами.

Объяснение этому нахожу в том, что на момент принятия ключевых решений по дизайну Java (а это конец 1980-х и самое начало 1990-х) не был накоплен еще достаточный опыт использования исключений в промышленных масштабах.

Если правильно помню, из более-менее известных на тот момент языков, исключения были в SmallTalk, Ada и Eiffel (но в Eiffel они сильно специфические, не такие, как в C++/Java/C#). Даже в C++ исключения были только описаны, но компиляторы с поддержкой исключений стали появляться только в начале 1990-х.

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

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

https://wiki.python.org/moin/PythonTestingToolsTaxonomy#Fuzz_Testing_Tools

Ещё враппер вокруг afl есть.

Если вы про white box fuzzing, то таких вроде бы нет.

То, что станет в будущем check - это то же, что ф-я без блока except, которая просто «прозрачна» для пролетающего в неё исключения. То же и функция, в которой не вызывается recover. К вопросу контролируемости исключений это, как мне кажется, ортогонально.

просто «прозрачна» для пролетающего в неё исключения

Здесь ты расписал «условную последовательность действий», или «поток управления». Ты хочешь «метафункцию», которая явно оперирует с объектами-исключениями, но не хочешь его замечать/писать. При этом эта «метафунция» будет явно напоминать о себе, когда ты вылезешь на этот «метауровень», захочешь контролировать исключения, захочешь управлять потоком управления: например как в потоках, корутинах, межпроцессном взаимодействии и тп.

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

Особенности исключений в плюсах.
В жабке метод обязан объявить бросаемые исключения.
Кроме RuntimeException, но то что-то вроде panic.

Это в большинстве языков с исключениями так.

Вместо того, чтобы разобраться объявлять все непонятное религией это так логично. Ссылки на то, что появляется второй неочевидный control flow уже были. Кроме того панику можно ловить исключительно в рамках одной горутины, и соответственно вся конкурентность ломается: https://play.golang.org/p/qEsA4dR0w_6

Панику можно использовать если у тебя исключительная ситуация, например отсутствует необходимая для работы сервиса зависимость во время инициализации (отсюда всякие MustGetBlah), или есть глубоковложенные циклы. Но паники должны на верхнем уровне ловится и превращаться в ошибку: https://golang.org/src/encoding/gob/decode.go?h=catchError#L1086 https://golang.org/src/encoding/gob/error.go?h=catchError#L34

Еще у многих есть привычка просто выбрасывать ошибку наверх вместо обработки. «Errors are values» как раз про это - https://golang.org/src/os/error.go Ошибки это тоже данные и с ними нужно работать как и с другими данными - https://dave.cheney.net/practical-go/presentations/qcon-china.html#_error_han...

удобный оператор ?

И в каком это месте он удобный, если с его помошью нельзя вернуть чужую ошибку (когда реализую трейт надо) и нельзя дописать в ошибку инфу из контекста (например имя файла, который не получилось прочитать). Приходится map_err перед вопросом добавлять. У монад, в отличии от этого макроса, более широкая область применения.

Есть кстати один случай, когда возвращать ошибку стопроцентно не нужно. А именно когда уверен, что ее там быть не может. Например если положил элемент в массив и следующей же строкой вытащил первый или последний элемент массива. Более того, есть смысл использовать ассерты, которые добавляют вариантов с паниками в код на фазе разработки, потому что вовремя упавшая программа лучше неправильно работающей (да и как обработать проблему, причиной которой является инвалидность самого кода программы, не автофиксом же кода). Причем иногда это верно даже для релиза. Разве что в задаче требуется корректно завершится, например аварийно посадить беспилотник...

Вместо того, чтобы разобраться объявлять все непонятное религией это так логично.

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

Но паники должны на верхнем уровне ловится и превращаться в ошибку

Разве я это отрицал? Это очевидно, вроде. Если применять их шире, то это правило обобщается до «панику нужно ловить на соответствующем уровне и либо устранять её последствия, либо превращать в ошибку».

Еще у многих есть привычка просто выбрасывать ошибку наверх вместо обработки

Так это ортогонально к способу обработки:

func callDangerous() (err error) {
 err = dangerous()
 return }

func callDangerous() throws {
 dangerous()
}