Вот хотелось if err != nil { log.Fatal(“error”) } написать статью, где if err != nil { log.Fatal(“error”) } я бы обругал гошную if err != nil { log.Fatal(“error”) } модель работы с ошибками if err != nil { log.Fatal(“error”) }, потому что if err != nil { log.Fatal(“error”) }из за нее код if err != nil { log.Fatal(“error”) } становится менее if err != nil { log.Fatal(“error”) }, сука, читаемым.
Как обычно, перед написанием поста в блог, я начал рисерчить и наткнулся на клевую статью Дэвида Никса: Error Handling in Go.
И вот обратите внимание на этот абзац:
Interpreted languages, like Ruby, are more concise because you aren’t required to handle exceptions at all. Swift and Java won’t compile until you force the caller to handle the exception. Go won’t compile unless the caller handles or ignores the error value.
И все становится на свои места. В Похапе, Питоне, Руби можно вообще не обрабатывать ошибки и ложить на обработку исключений. Пиши как есть, не надо ничего хендлить, получай читаемый код… Главное потом на продакшене не обосрись!
Однако, остается открытым вопрос читаемости кода. Вот, например, автор треда про хендлинг ошибок в Го на Реддите поднимает мучающий меня вопрос: https://www.reddit.com/r/golang/comments/3sfjho/gos_error_handling_is_elegant/cwxozq9/
Кусок кода на Java читается и воспринимается лучше, чем кусок кода на Го, где логика работы разрывается обработкой ошибок.
И понятно, что Роб Пайк и команда превратили ошибки у Го в значения переменных, которые дешевы и их можно перекидывать куда угодно без проблем производительности.
Однако код теперь читается хуже.
Кстати, весь тред обсуждения обработки ошибок в Го очень интересный https://www.reddit.com/r/golang/comments/3sfjho/gos_error_handling_is_elegant/.
Ну и в общем, для Го 2 комьюнити кидает всякие пропоузалы по поводу обработки ошибок. Из всего мне достойным показался вот этот вариант с ключевым словом check: https://github.com/golang/go/issues/21161#issuecomment-318350273
Получается вот такая элегантная штука. Но это не уводит нас далеко от паттерна checkErr(err) или panicIf(err). Все равно под каждым вызовом функции надо писать кусок кода обработки ошибки, хоть и в одну строку.
Надо ФУНДАМЕНТАЛЬНО избавлять язык от возврата ошибки вторым возвращаемым значением. А на это уже никто не согласится. Можно сказать, что обработка ошибок в Го попала в капкан “тут так принято”.
Ранее статья была опубликована тут.