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

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

почему?

потому что 1) это довольно частая тривиальная операция 2) во многих языках это делается с помощью 0 строчек кода, то есть автоматически

точнее почти во всех языках

так а минусы то какие?

если вы так быстро придумываете код, что вас тормозит написание 3х строчек, то поздравляю

на это есть шорткаты в редакторе

а давайте вместо знака + писать add_two_numbers?

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

ведь есть шорткаты в редакторе

дело в том, что простые вещи должны делаться просто

давайте вы не будете передёргивать, это неуместная аналогия

если вы этого не понимаете, то мне не очем с вами больше разговаривать

вас просто бомбит, с кем не бывает. гнев - первая стадия

я не знаю о чем и с кем вы тут обсуждаете свои вкусы динамических языков программирования, при это уже давно :(

no offence

я не знаю о чем и с кем вы тут обсуждаете свои вкусы динамических языков программирования, при это уже давно :(

динамика тут не причём вообще

абсолютно

вас просто бомбит, с кем не бывает. гнев - первая стадия

что касается go и его дурацкой работы с ошибкой, у меня дальше первой стадии не заходит

динамика тут не причём вообще

в си есть эксепшны? паттерн матчинг? или что вы там еще упоминали?

ну, люди меняются :)

в си есть эксепшны? паттерн матчинг? или что вы там еще упоминали?

При чём тут Си вообще????

в си есть эксепшны? паттерн матчинг? или что вы там еще упоминали?

там ещё конкаренси и сборки мусора нет :)

В C++ есть эксепшены, в Java, C#, Python, JS и ещё кучи мест. Там где нет эксепшенов почему то вводят всякие краткие и удобные штуки для их замены. В Go так не сделали

в го есть паники

В C++ есть эксепшены, в Java, C#, Python, JS и ещё кучи мест. Там где нет эксепшенов почему то вводят всякие краткие и удобные штуки для их замены. В Go так не сделали

Видел самописный костыль на panic() recover() который эмулирует исключения, но считается плохой практикой

в го есть паники

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

Видел самописный костыль на panic() recover() который эмулирует исключения, но считается плохой практикой

Тоже кстати видел, и даже не один

в лиспе нет исключений

лисп даже старше чем си

в лиспе нет исключений

В лиспе наверняка есть средства простого проброса ошибок

А средства сделать такой проброс (если его нет) точно есть

в swift говорят нету тоже

В C++ есть эксепшены, в Java, C#, Python, JS и ещё кучи мест. Там где нет эксепшенов почему то вводят всякие краткие и удобные штуки для их замены. В Go так не сделали

это утверждение, да, что вы тут обсуждаете? :(

http://xahlee.info/comp/why_i_hate_exceptions.html

http://xahlee.info/comp/why_i_hate_exceptions.html

basically, exceptions are invisible gotos уже можно поспорить

в swift говорят нету тоже

вообще то есть

а, старые данные значит

в swift говорят нету тоже

а еще там есть паттернг матчинг и еще очень много всякого вкусного, не зря его сейчас активно тянут в серверную разработку

basically, exceptions are invisible gotos уже можно поспорить

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

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

я осилил го, но мне больно на нём писать и я закономерно бомблю

Я в своем коде каждую ошибку оборачиваю в другую ошибку с доп информацией, которую считаю нужной (метка места возникновения, может переменные, может текст), и ее уже возвращаю. Типа myerrors.New(“myfunc: err with path: “, path, err). Такая вот эмуляция стектрейса. В конечном счете жить можно.

а еще там есть паттернг матчинг и еще очень много всякого вкусного, не зря его сейчас активно тянут в серверную разработку

эхем, язык без зафиксированного API не готов для серверной разработки, помоему

вообще то есть

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

короче реализация обработки ошибок близка к идеальной

https://docs.swift.org/swift-book/LanguageGuide/ErrorHandling.html кому интересно

А вообще, к го2 подумывают что-то с ошибками сделать (сделать их типизированными вроде), но это не точно)

А вообще, к го2 подумывают что-то с ошибками сделать (сделать их типизированными вроде), но это не точно)

go2 еще даже не на горизонте, а до его выхода уже столько всего понапишут, что переход индустрии с питона 2го на питон 3ий покажется легкой прогулкой

А вообще, к го2 подумывают что-то с ошибками сделать (сделать их типизированными вроде), но это не точно)

хм, а сейчас ошибки нетипизированные?

А вообще, к го2 подумывают что-то с ошибками сделать (сделать их типизированными вроде), но это не точно)

https://github.com/golang/go/issues/21161 обсуждение идет с прошлого года, много разных идей

go2 еще даже не на горизонте, а до его выхода уже столько всего понапишут, что переход индустрии с питона 2го на питон 3ий покажется легкой прогулкой

вы переходили с питона 2 на 3? знаете что там было камнем преткновения?

вы переходили с питона 2 на 3? знаете что там было камнем преткновения?

То, что третий питон не обладает тьюринг-полнотой?

То, что третий питон не обладает тьюринг-полнотой?

о, добрый день, как там дела в том языке, где все есть? :)

о, добрый день, как там дела в том языке, где все есть? :)

Неправда, HKT нет

хм, а сейчас ошибки нетипизированные?

errors.New() - просто текст. В стандертной либе некоторые с доп кодами.

вы переходили с питона 2 на 3? знаете что там было камнем преткновения?

в основном изменения в строках и изменения в стандартной либе, когда функции начала возвращать генераторы, там где раньше возвращались коллекции

То, что третий питон не обладает тьюринг-полнотой?

Несмешная шутка

errors.New() - просто текст. В стандертной либе некоторые с доп кодами.

что вам мешает использовать типизированные ошибки? реализовать интерфейс error очень просто, можете не благодарить

что вам мешает использовать типизированные ошибки? реализовать интерфейс error очень просто, можете не благодарить

Так я не за себя беспокоюсь)

что вам мешает использовать типизированные ошибки? реализовать интерфейс error очень просто, можете не благодарить

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

А зря

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

можно развернуто? в общем случае, имеется ввиду division by zero и прочее? то есть не руками сделанные ошибки?

что вам мешает использовать типизированные ошибки? реализовать интерфейс error очень просто, можете не благодарить

вот тут есть подводные камни

err != nil перестанет работать

что вам мешает использовать типизированные ошибки? реализовать интерфейс error очень просто, можете не благодарить

а через switch проходится по типу ошибки (структуры)?

ERROR: S client not available

потому что интерфейс

??????

а через switch проходится по типу ошибки (структуры)?

А где гарантия, что ты переберёшь все возможные типы ошибок, возвращаемые из функции?

А где гарантия, что ты переберёшь все возможные типы ошибок, возвращаемые из функции?

скорее это для того чтобы отловить некоторые специфичные виды ошибок, а стандартное поведение будет в default

потому что интерфейс

https://blog.golang.org/error-handling-and-go тут есть примеры

??????

https://divan.github.io/posts/avoid_gotchas/#interfaces

скорее это для того чтобы отловить некоторые специфичные виды ошибок, а стандартное поведение будет в default

А что в default?

А где гарантия, что ты переберёшь все возможные типы ошибок, возвращаемые из функции?

хм, а в языке, который нельзя называть, тебя обязывают обработать все возможные типы ошибок? :O

хм, а в языке, который нельзя называть, тебя обязывают обработать все возможные типы ошибок? :O

Да. Без этого просто не скомпилируется

гуд джоб, наверное

А что в default?

стандартное поведение P.S - типизированые ошибки я рассмартриваю исключительно как контейнер с доп. информацией об ошибке, напр. последний запрос с БД который отвалился или что то еще

https://divan.github.io/posts/avoid_gotchas/#interfaces

что именно? nil interface? возращаете nil, когда ошибки нет, и все будет ОК

что именно? nil interface? возращаете nil, когда ошибки нет, и все будет ОК

Раз уж мы заговорили об ошибках, есть какой то способ обернуть обработку ошибок, чтобы 30% кода не состояло из if err != nil

как Result в расте

Раз уж мы заговорили об ошибках, есть какой то способ обернуть обработку ошибок, чтобы 30% кода не состояло из if err != nil

насколько я знаю нет, но вы что-то делаете не так, или у вас проект из 10 строк, если 30% кода if err != nil

как Result в расте

Без try! или ? обработка ошибок была бы столь же многословной, как и в Go

что именно? nil interface? возращаете nil, когда ошибки нет, и все будет ОК

я ж вам ссылку дал. если вы возвращаете типизированную ошибку без проверки, и внутри неё nil, то она на пройдёт стандартную проверку err != nil

я ж вам ссылку дал. если вы возвращаете типизированную ошибку без проверки, и внутри неё nil, то она на пройдёт стандартную проверку err != nil

если вы возращает nil явно, все будет ОК

насколько я знаю нет, но вы что-то делаете не так, или у вас проект из 10 строк, если 30% кода if err != nil

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

с одной стороны можно забить и юзать _ но это не по канону

иногда и правда зря есть возврат ошибки, бывает

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

что вам мешает использовать типизированные ошибки? реализовать интерфейс error очень просто, можете не благодарить

https://play.golang.org/p/BB1b2_HDb6I

попробуйте сказать, какая ветка выполнится до Run

именно поэтому вам нельзя возвращать типизированную ошибку, только интерфейс

ну или можно, если ваш код видите только вы

https://play.golang.org/p/BB1b2_HDb6I

https://play.golang.org/p/R9Jg_9-PyM4

можно и нужно возвращать типизированные ошибки

так вы интерфейс возвращаете

что вам даст типизированная ошибка, если внешний код видит только метод Error()?

придётся кастовать

эм, а паттерн матчинг что делает по вашему?