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

Всё нормально, вебсервер должен отдавать 500.

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

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

А если я не знаю состояние программы, то где гарантия, что она будет продолжать отдавать 500, а не зависнет? «Будем надеяться, что не зависнет»?

Тогда ты что-то не так спроектировал.

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

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

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

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

Я осознал то, что в этом подходе есть дефект. См. пример с FFI. Это вы не понимаете. Уже десятый раз одно и то же пытаюсь объяснить. На твоём языке получается, если сложить то, что вы говорите, то оказывается, что паники тоже нужно сортировать на «плохие» и «не очень». Если FFI поломало память, то надо падать, а если ошибка в логике, но затрагивает только часть веб-приложения и не приводит к разрушению инфраструктуры, не мешает продолжению других обработчиков, то нужно эту панику напечатать в лог и продолжить работу.

То же касается и ошибок. Если пришло err, то это не значит, что программа не должна упасть прямо сейчас по Os.exit(1)

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

Описанный случай с FFI это опять косяк архитектуры и вообще фейл, да ни в одном языке нет приёмов против unsafe-кода.

Т.е. реакция на ошибку мало зависит от того, выражается ли эта ошибка как паника или как err

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

Описанный случай с FFI это опять косяк архитектуры

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

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

Допустим.

Но как валить этот сервер? А вот как: не с помощью паники, а с помощью os.Exit. Так что, как вы не прячтесь, но формула «для обычных ошибок - err, для необычных - паника» - не работает.

Ну, смотри, как проще всего (случайно) сломать программу из ffi так, чтобы это было необратимо и ничего не оставалось, кроме падения? Проще всего сломать внутреннее состояние объектов языка. Но от этого спасают высокоуровневые библиотеки. Если их не юзают, значит целенаправленно стреляют по ногам. Тут возникает вопрос, почему вообще до этого дошло? Это более чем просто программная ошибка, скорее всего виновато проектирование.

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

Аргументация в направлении тезиса «использовать FFI - это ошибка проектирования» не принимается.

Но допустим, мы не авторы голанга с отмороженной головой и у нас есть проблемы с FFI. Прежде всего, мы наставим ассертов, которые вроде тут объявлены астрологией и чёрной магией.

Когда такой ассерт не прошёл, паниковать нет смысла, надо сразу вызывать exit(1). Если образ сломан, то даже это может не помочь, но паниковать со всеми defer-ами в сломанном образе точно не нужно.

Паника не для обычных или необычных ошибок, а особых случаев и разрабов, которые способны их определить. В общем случае никаких паник быть не должно. Don’t panic.

Аргументация в направлении тезиса «использовать FFI - это ошибка проектирования»

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

Ну это тоже неубедительно. Ведь либы для FFI тоже писали не боги.

Так в каком «общем случае»? По твоей ссылке приведены конкретные примеры ситуаций, когда панику можно использовать, и для случая FFI там написана неправда.

Ты сказал:

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

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

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

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

По твоей ссылке приведены конкретные примеры ситуаций, когда панику можно использовать

Где приведено и в каких это случаях?

Ты сам-то свою ссылку на don't panic читал?

Паника тебе тут не пригодится, всё свалится прежде,

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

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

Не нужно её применять, ёпт.

А это ты писал, что находишься тут только ради срачей?

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

не нужно

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

В приложении можно вызывать os.Exit в каких-то случаях, в библиотеке - нельзя. Деферы чаще всего должны выполняться даже при непрошедшем ассерте.

Всё таки почитай что такое graceful shutdown.

Ты просто привык ломать образ а Лиспе. Чтоб такого добиться на го надо очень постараться.

Лисп в среднем примерно так же надёжен, чем голанг, и ломается примерно в тех же ситуациях. Ладно, когда-нибудь составим перечень ситуаций и для каждого я опрошу ъ гоферов, какая тут должна быть обработка. Но это будет чисто вопрос культуры.

Всё же ещё раз отмечу, что высказывания типа этого

GO does not have an exception mechanism you can't throw exceptions. During the execution when Go detects these mistakes, it panics

и

Go has no try/catch mechanism. The reason for this is simple: there is no exception.

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

Также очень плохой совет в effective go вот такой:

If the problem can be masked or worked around, it's always better to let things continue to run rather than taking down the whole program.

Такой подход растит проходимцев от инженерии. Я вижу его везде вокруг, но это не значит, что я с ним согласен.

И наконец, так и не достигнуто понимание гоферами того, что паника и возврат err - это два способа добиваться одного и того же результата, причём паника (исключения) - как правило, более удобна. А возврат ошибки в идиоматичном виде, когда возвращается просто error, который ни о чём - это плохая практика. Конструкция

if err != nil { 
  return
}

По хорошему, если уж обрабатывать ошибки, то их нужно тщательно сортировать, и этот синтаксис (со switch) едва ли не многословнее блока except.

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

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

И работают по-другому, угу.

Также очень плохой совет в effective go

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

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

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

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

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

И работают по-другому, угу.

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

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

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

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

3) Могут ли фичи не выгодные создателем попасть в Го?

Какие, например, фичи не выгодны создателям Го? Разве такое может быть? Почему?

Вот, читаю:

https://jobs.zalando.com/tech/blog/hack-to-terminate-tcp-conn-postgres/?gh_sr...

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

Через год удивиться, что клиенты закончились.

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

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

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

Насчёт обработки дефёров при панике я могу ещё один пример привести:

r, err := resource.Open()
if err != nil {
 return err
}
defer r.Close()
r = nil
r.Method()

Важная правка) Такой код у меня бы тоже ревью не прошел. Ну и фиксится элементарно же.

Такой код у меня бы тоже ревью не прошел

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

Вот статейка про использование паники.

https://hackernoon.com/panic-like-a-pro-89044d5a2d35

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

Впрочем, тут можно напороться. Я вчера искал использование Log.Fatal и нашёл море, но это всё было в тестах.

GUI

Кстати, реально заговор какой-то. Там даже биндинги к ncurses в зачаточном состоянии и заброшены. Где-то прочитал, что комьюнити мол не интересуется гуями. Это просто лол. Первое, что интересует программиста, решившего сделать что-то практически полезное, это гуи-библиотеки. На любом мейнстримном языке можно сделать гуи любой сложности, но только не на го.

Это не заговор. Го поделие гугла. Он используется на серверах. Там GUI не нужен. Если кто то попробует скажем портировать wxWindows на Го, то это ваши проблемы. Оно вам надо? А главное в Го будут постоянно вносить изменения (что там с GOPATH)...

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