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

Владимир

Спасибо!
Добротный анализ ...
Моя любимый «Helllo World» - код подсчета суммы натурального ряда чисел от 1 до 100.
Так даже такой код в go не опробовал /других задач много/.
Но вот с архитектурой объектов go познакомился - на первый взгляд весьма толково.
Если этот язык не превратят в мусорную свалку, то буду рад за него.

Скорее всего текст go легко конвертируем к C /со всеми вытекающими .../

Речь про панику в обработчике.

А иметь три машины ради какого-то тривиального сайтика - это перебор.

Так для тривиального сайтика не нужно никакого приложения. В лучшем случае скрипты на PHP, а то и вовсе можно сгенеренной статикой обойтись. А для нагруженного сервиса может понадобится не 3, а все 33 машины.

Нет исключений — ничего не платишь.

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

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

Практика показывает, что еще как смешиваются. Смотря какие условия задачи. Веб-сервер и сервер приложений так вообще испокон веков смешивают, начиная с Апача.

Веб-сервер и сервер приложений так вообще испокон веков смешивают, начиная с Апача.

Это как раз прошлый век. Никто сейчас сервер приложений голой жопой в инет не выставляет.

В Scala их нет. Потому как тип Option и стандартная обработка исключений покрывают все юзкейсы checked exceptions.

Что, очень сложно? Если к ошибке привел ввод-вывод, то есть ошибка в чем-то внешнем, тогда ее следует обработать. Если ошибка где-то в твоем коде, тогда что-бы ее обработать нужно пофиксить баг, в таком случае надо падать. Это не маркетинг, а здравый смысл. Именно для таких случаев придумали паники.

Никто сейчас сервер приложений голой жопой в инет не выставляет.

Но однако же все современные серверы приложений в том или ином виде поддерживают HTTP, то есть по факту являются веб-серверами

Можно пример где необходима паника?

У меня недавно было, был дженерик параметр реализующий crypto_mac::Mac у него есть метод

fn new_varkey(key: &[u8]) -> Result<Self, InvalidKeyLength>

Смотри здесь.

Мой код был что-то типа

impl<T: Mac> Foo<T> {
    fn bar<B: AsRef<[u8]>>(key: &B) {
        ...
        T::new_varkey(key.as_ref()).unwrap()
        ...
    }
}

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

Я написал комментарий что то что сюда подставляется должно мочь создаваться с ключами любой длины и .unwrap(). Это нельзя было выразить в типах.

Если это нарушится, то просто в мой тип подставили неподходящий тип, а требование невозможно было формально описать. Это нельзя никак обработать.

Почему бы не пробросить ошибку?

В моём случае это, например, неудачный коммит транзакции по неизвестной причине

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

Хорошо, вы работаете с деньгами, произошел какой-то нереальный 3.14 на интегрируемой бирже, вместо нужного вам ордера начали создаваться очень кривые. В секунду тысяч 5-10 таких вот ордеров - т.е. В таком случае кидать простой warn или error в систему уведомлений просто опасно. Человек может не среагировать. Робот же в свою очередь не сможет правильно решить проблему. Это раз.

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

Я это к чему: тут смотря что важнее, репутационные потери или же финансовые. В любом случае в первую очередь головой надо думать, а то вот эти слова

Программа не должна падать в принципе

Приводят к реальной жести

Я использую panic'у только там где реально программа не может продолжить работу (при инициализации база не работает например), err использую в остальных случаях. Лично мне неприятен подход через ручную проверку err, но такого цена. Я бы предпочел анало питонячьих исключений.

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

Эм,

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

Ну т.е. если бы они были обработаны то было бы совсем иначе :)

Я например словил несколько игноров ошибок при работе с ценой в одном проекте, что-то типа

price, _ := getPrice(...)

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

А в Python встречал вообще вот такое:

raise RuntimeError(...) from None

И иди ищи откуда что прилетело...

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

весело игнорируемая ошибка ... сплошь и рядом в Go

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

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

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

Безусловно.

А как ее обработают?

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

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

if r.is_err() {
    /* ну ладно, раскусили, делаю нормально */
}

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

Ну это уже не столько ошибка, сколько unreachable. Это совсем другая история.

Вспоминается f64::from_str_radix который паникует, если левый radix подставлен. Но в данном случае это можно решить типами, правда это будет длинный enum от 2 до 36.

Это вопрос философии. Скрипты могут падать. Сервер - ну может. GUI - ни в коем случае.

получил периодическую рассогласованость в базе.

Для этого есть транзакции.

Если это данные не извне, созданные внутри программы и не константные. Тогда нужно именно падать. Потому что в таком случае что-бы разрулить ситуацию нужно сесть и подумать. А программа сама это сделать не может.

Всё равно не вижу причин падать. Я стараюсь писать код так, что там нет паник в принципе.

Согласен, что все эти ситуации теоретически можно «обработать» во время написания кода и паник не будет вообще. Так и нужно делать в идеальном мире.

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

Весь серьезный софт так и делает. У меня хром за последние лет 5 падал пару раз всего, и то небось из-за иксов/дров.

«Плазма падает» - это вот из-за такого подхода к написанию софта, когда падение - это норм.

Это сектантство какое-то «падения норм», «падения не норм». Я дал критерий когда должно быть падение. Отсутствие падений нужно добиваться не сектантством, а тупо человеко-часами.

Программа верно работает - сектантство. Втф?

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

Именно для таких случаев придумали паники.

Давай начнём вот с чего. Где бывает безплатный сыр? Есть основания подозревать, что маркетологи учат не совсем тому, чему надо. Дальше, как падают? os.Exit(1). Паника - это не совсем падение, до падения оно обработает все defer-ы. Где гарантия, что наш баг не введёт эти defer-ы в ступор? Программа может не смочь упасть, в зависимости от бага. Значит, обработки баги паникой - это неверный подход, ненадёжный.

Отсюда очень простой вывод (смотри, мои руки перед тобой, я нигде не мухлюю). Если надо падать, то паника не подходит.

Дальнейшее я описал чуть выше по теме. Есть категории серьёзности ошибки (например, падение программы, падение обработчика одного запроса к сервису, предупреждение в лог), и есть способы их обработки. Что err != nil, что паника в вычислительном отношении абсолютно одинаковы. У тебя есть какая-то НЁХ. В одном случае это значение с ни к чему не обязывающим интерфейсом err, а в другом - это ни к чему не обязывающее значение, возвращённоё из recover.

Случай паники сводится к случаю возврата err примерно так:

// было
func f1 () (res int, err error) {
 return 0, errors.New("Беда")
}

func main() {
 res, err = f1()
}

// стало
func f2 () (res int) {
 panic(errors.New("Беда"))
}

res, err = func() (res int, err error) {
 defer func() { err = recover() }
 res = f2() 
 return
} ()

Т.е. эти механизмы с вычислительной точки зрения тождественны

Нет. Остальное даже комментировать лень.

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

Кстати, есть ли где-нибудь чёткое определение, что такое «действительно исключительная» ситуация?

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

На самом деле серьёзность ошибки не так связана с тем, какой механизм нужно применять.

А кто говорил о серьезности? Я говорил о источнике ошибки. Почти всегда это ввод-вывод, это нужно обрабатывать. Если источник ошибки внутри твоего кода, тогда нужна паника. И там и там могут быть серьезные и несерьезные ошибки.

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

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

Я надеюсь, ты согласен, что падать с помощью паники нельзя. Тогда, если не влом, будь добр, опиши область применения паники в виде чёткого определения, а не просто «ошибка где-то в моём коде».

Я надеюсь, ты согласен, что падать с помощью паники нельзя.

Можно. gin - отдельная история.

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

Паника если контракт между частями твоей программы в рамках одного бинарника нарушен. Классический пример: значение переменной должно быть между 100 и 100500, а оно прилетело 100501, причем прилетело не из сети и не из пользовательского ввода и не из другого внешнего источника, а вычислено в твоем же коде. Тогда паника.

Т.е. то, что defer может, вообще говоря, зависнуть и упасть не удастся, для тебя не аргумент?

Не пиши такой defer. Gin так написан, потому, что веб сервер вообще не должен падать.

Смотри:

package main

func trap(n int) {
 defer func() { if n>100500 {
  for {}}}()
 if n<100 || n>100500 { panic("Wrong n") }
}
func main() {
 trap(100501)
}

Если я пишу библиотеку, я не отвечаю за все defer-ы на стеке.

Если пишешь библиотеку, отвечай за свои деферы. А за пользовательские пусть отвечают пользователи.

И еще. Паника в библиотеке, которая будет приводить к падению приложения нужна бывает только в исключительных случаях. А за os.Exit в библиотеке я бы вообще расстреливал.

Согласен с feofan, не пиши такие defer'ы.

В каких исключительных случаях нужна паника? Дай определение.

Влад дал хорошее определение: паниковать нужно в ситуациях, которые исправляются только изменением кода

Ну так мне кто-нибудь даст определение особенно исключительных случаев, когда паника всё же нужна?

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

Влад дал хорошее определение: паниковать нужно в ситуациях, которые исправляются только изменением кода

Давай сравним это определение с другим, которое я дал: падать (не важно, через панику или нет) нужно в том случае, когда контроль и понимание потеряны и мы не знаем, что вытворит наша программа, если ей дать продолжать работать. Согласен или нет?

Как-то сумбурно, но с идеей я согласен

Отлично, если мы потеряли контроль над состоянием программы, зачем нам падать с помощью паники, а не с помощью более надёжного Log.Fatal aka os.Exit(1)?

Я уже приводил пример FFI. Не знаю, как в го, а обычно FFI может повредить память приложения. В языке со сборкой мусора это особенно страшно. И вот мы написали, прости господи, некий assert, который хоть как-то проверяет вменяемость программы после возврата из FFI. Допустим, этот assert не прошёл. Особо нечего здесь обсуждать, кроме os.Exit(1) тут нет вариантов, т.к. у нас может быть повреждён и стек, в результате чего паника не сможет выполниться. Но не буду об этом спорить.

Давай вынесем за скобки эту ситуацию потери контроля над состоянием приложения. Какие ещё ситуации подходят для паники?