В 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 проходится по типу ошибки (структуры)?

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

??????

а через 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()?

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

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

а при чём здесь это?

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

при том, что так работают с типизированными ошибками в go

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

https://golang.org/src/os/error.go?s=2567:2597#L78

https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully

хорошая статья, читал когда-то

вы её тоже читали, надеюсь?

всем доброго времени суток есть структура type MyTable struct { name string Id int } есть запрос в БД SELECT name, array_agg(id) from my_tables group by name; есть описанная модель в go-pg Вопрос: Могу ли я получить array_agg через модель go-pg или придется делать обычный запрос через Exec или Query

https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully

вы её тоже читали, надеюсь?

вы, видимо, на этом остановились, и читать дальше не стали

так мы с вами про типизированные ошибки спорим. нет разве?

просто вы дали этот совет как панацею

так мы с вами про типизированные ошибки спорим. нет разве?

Assert errors for behaviour, not type

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

ну ок, значит я вас неправильно понял. Я подумал, что вы предлагаете тупо возвращать тип, который удовлетворяет интерфейсу error