Daniel
генерики не запихнули
$continue$
Всем привет. Кто использовал revel? Написано, что он фулл стэк, но вопрос, как в нем бэкенд использовать?
Прощу палками не кидать 😭
Алексей
https://github.com/albrow/fo
Алексей
это в другом чате. но замечу, что с эксепшенами народ вытворяет другое, но такое же гнусное непотребство
Кстати, а что за непотребства?
Maksim (Ellrion)
а, то есть ошибки по умолчанию стектрейса своего возникновения никак не содержат
замечательно!
для ошибок нормально юзать что то типо https://godoc.org/github.com/pkg/errors или свое похожее. но на ошибки внутри пакетов конечно это не повлеяет
Алексей
для ошибок нормально юзать что то типо https://godoc.org/github.com/pkg/errors или свое похожее. но на ошибки внутри пакетов конечно это не повлеяет
да, я находил похожий сторонний пакет
kås
и что все пишут одну строчку логики и три боилерплейта?
ну можешь вот так сделать, как вариант
check(err)
func check(e error) {
if e != nil {
handle
}
}
Maksim (Ellrion)
ну можешь вот так сделать, как вариант
check(err)
func check(e error) {
if e != nil {
handle
}
}
если там не panic и не os.Exit() то то что ты написал не поможет от https://t.me/gogolang/116574
Maksim (Ellrion)
а их применять можно очень не всегда
Алексей
https://blog.golang.org/defer-panic-and-recover
For a real-world example of panic and recover, see the json package from the Go standard library. It decodes JSON-encoded data with a set of recursive functions. When malformed JSON is encountered, the parser calls panic to unwind the stack to the top-level function call, which recovers from the panic and returns an appropriate error value
Исключений как бы нет в Golang, но они есть.
kås
ну если 20 однотипных проверок, можно их вынести в 1 общую. С едиными return values, etc
Алексей
kås
да, ты прав
Constantine️
Алексей
не ну можно конечно оставить самый последний if в некоторых случаях, но это не совсем правильно на мой взгляд
Алексей
if er != nil {
}
.
except BasicException:
pass
Tigran
Алексей
во во
Илья
ну, линтеры на такое ругаются, обычно
Алексей
ну то есть фактически ситуация от пустого catch не отличается ничем
Denis
на присвоение blank identifier _ по дефолту линтеры не ругаются, надо включать явно опцию errcheck
Sebor▂▅▇█▓▒░
Да, с ошибками беда в го
Я в этом случае просто смотрю код какого-нибудь крупного проекта)
Те же докер, кубер
Denis
хотя gas по дефолту ругается
.
А чем обработка в Go хуже чем в других яп? И где она хороша, если так говорить уже
Алексей
А чем обработка в Go хуже чем в других яп? И где она хороша, если так говорить уже
Везде лучше, чем в Go.
.
Спрашиваю же — чем?
Алексей
тем что эксепшены содержат стектрейс по которому можно отследить место возникновения ошибки
.
Ну а в других яп бесконечные try catch
.
Приведите пример
Алексей
Приведите пример
//JS
try {
//огромное количество кода с кучей вызовов функций
} catch (e) {
console.log(e);
}
Kirill
//JS
try {
//огромное количество кода с кучей вызовов функций
} catch (e) {
console.log(e);
}
Ужас же. Никакой обработки ошибок, тупо в консоль пользователю срать, жесть
Алексей
Ужас же. Никакой обработки ошибок, тупо в консоль пользователю срать, жесть
это для примера же
Kirill
Равен хотя бы прикрутили бы
Алексей
в catch что угодно может быть
Cat
Ужас же. Никакой обработки ошибок, тупо в консоль пользователю срать, жесть
s/console.log(e);/throw e/g
Илья
exit(0)
Kirill
а в го не так разве?
value, err = get(); err != nil {
return nil, err
}
if value, err := someFunc(); err != nil {
switch err.(type) {
case ErrConnLost:
sendAlert(err)
reconnect()
ctx.Err500()
// more cases here
}
}
Cat
if value, err := someFunc(); err != nil {
switch err.(type) {
case ErrConnLost:
sendAlert(err)
reconnect()
ctx.Err500()
// more cases here
}
}
catch ExceptionTypeA: {
do_smth()
}
catch ExceptionTypeB: { ... }
Cat
из головы синтаксис выдумал, не знаю как там на первоисточнике
Алексей
func mainFunc() (int, error) {
r1, err := func1()
if err != nil {
return 0, err
}
r2, err := func2(r1)
if err != nil {
return 0, err
}
r3, err := func3(r1, r2)
if err != nil {
return 0, err
}
return r1 + r2 + r3, nil
}
vs
function mainFunc() {
const r1 = func1();
const r2 = func2(r1);
const r3 = func3(r1, r2);
return r1 + r2 + r3;
}
Алексей
проблема Go в том, что приходится обрабатывать ошибки даже тогда, когда по логике не нужно обрабатывать ошибки (точнее нужно их просто прокинуть вверх по стеку)
Алексей
а блин
Kirill
Вы забываете, похоже, что можно не делать обертку, когда даже обработки ошибок вообще не будет
Maksim (Ellrion)
Гора синтаксических ошибок %)
щас бы к псевдокоду придераться который идею показывает
Roman
Но смысл ведь понятен.
Алексей
Cat
Вы забываете, похоже, что можно не делать обертку, когда даже обработки ошибок вообще не будет
и словить nil dereference
Cat
я тогда совсем не понял
Алексей
я чего то не понимаю, про какую обёртку идёт речь?
Алексей
Блин, от обработки ошибок в Go у меня бомбит больше всего. Самый главный и критичный недостаток Go.
Oleh
Алексей
Рили?
Знаком такой принцип DRY? Вот он в Go в плане ошибок нарушается очень активно, без добавления каких-либо существенных преимуществ.
Алексей
Сделали бы хотя бы какое-нибудь ключевое слово чтоли, которое автоматически бы проверяло наличие ошибки и с возвратом из функции этой самой ошибки. Было бы вообще огонь.
Vadim
Знаком такой принцип DRY? Вот он в Go в плане ошибок нарушается очень активно, без добавления каких-либо существенных преимуществ.
В го вообще dry, как я понял, не очень соблюдают.
Алексей
ну это плохо
Алексей
Кто-нибудь знает, будет ли это исправляться в Go2?
Алексей
Или "и так сойдёт"?