Я понимаю, почему вы ищете исключения в go — «привычный механизм», я не понимаю зачем? Например, вы привыкли ездить на велосипеде, видите как другие ездят на самокатах и удивляетесь — зачем они ногами от земли отталкиваются, есть же классная штука — педали, которые можно крутить… и ищете педали на самокате… даже где-то видели возможность прикрутить педали к самокату. Зачем? Если для вас важен механизм исключений при разработке, а обработка ошибок как возвращаемых значений в go кажется вам неудобной, не изучайте go. Есть множество других языков с исключениями.
Мне вот не понравился rust, не смог привыкнуть к его «свистульками и погремушкам», причем на уровне ощущений и эмоций, т.е. я не смогу объяснить — чем именно не понравился. Нет, так нет, я и не читаю статьи про rust.
Вы потролить зашли? :) Запрос в гугле «golang обработка исключений» выдает ответ на ваш вопрос на stackoverflow и несколько статей (в том числе и на хабре) про обработку ошибок в go.
Простите, но уровень лекций — «ниже плинтуса». Может, это слишком субъективно, но я не смог досмотреть ни одной лекции. Хватило терпения только на 3. Я понимаю — парни волнуются, они разработчики, а не преподаватели. Но тем более тогда лучше сделать публичную версию специально отснятой — с монтажем, дублями и т.п. Видео и так очень отстает от книг в плане скорости подачи информации, а в этих лекциях скорость становится просто черепашьей, к сожалению. ИМХО, книга Кернигана и Донована за аналогичное время даст больше информации и основы go будут понятнее.
Так никто и не утверждает, что лучше. Никто не агитирует за рипы с винила в flac. Иногда просто приятно вспомнить. Тут важен не контент, а воспоминания/эмоции, связанные с прослушиванием этого контента в прошлом. Я слушаю периодически Высоцкого — есть контент, очищенный от шума пластинок/пленок, а есть «рипнутый» как есть. Так вот второй мне иногда нравится больше, потому что вытаскивает воспоминания из детства… заметьте, я не «ною», не «вздыхаю» и не «онанирую» :)
Жаль. Совсем отвык от бумажных книг. А это какая-то юридическая особенность — у вас права на распространение именно печатной версии? Т.е. распространение электронной версии вам не разрешено или издательство считает этот вариант нерентабельным, к примеру?
я погорячился. Можно, конечно, и так тестировать.
ИМХО, у Финча вариант изящнее, а вариант Герранда более трудоемкий.
Спасибо за ссылки, первую положил в закладки — вдруг пригодится…
Подозреваю, что считали кодом все строки, которые не являются комментарием или пустой строкой. Возможно, 500 тысяч строк — это все репозитории с github.com/juju. В оригинале нет каких-то дополнительных сведений о методике подсчета. (Информация о том, что комментарии не учитывались, есть и в переводе)
Если честно, не понял… с exec.Command вы будете вызывать бинарник целиком; при этом вам надо как-то заставить его выполнить функцию, которая может вызвать os.Exit() и проверить код возврата. Здесь речь идет о
go test
и тестировании отдельных функций — запуском бинарника вы в этом случае не управляете. Да и это уже поведенческое тестирование, а не модульное…
Один из рецептов и приведен в статье. Можно ссылку, где почитать о других рецептах?
Про подход — наверное, да… я, кроме go, хорошо знаком только с python, и в нем есть такая общепринятая практика `if __name__ == '__main__"`… особенность go в том, что в нем недостаточно превратить функцию main в «однострочник» — все содержимое пакета main недоступно для импорта
Иногда приходится делать выбор. Например, между оверхэдом потоков информации между микросервисами и излишней связностью монолита. Команда, в которой работал автор, выбрала монолит. А как бы оно было, если бы команда выбрала микросервисы, никто не знает. Вряд ли кому-нибудь захочется переделать 500к строк кода на микросервисную архитектуру, чтобы посмотреть — как оно будет…
А сравнение с проектом на C# некорректное, да — там были другие люди, да и неизвестно, как он развивался. Вполне вероятно, что Juju на C# тоже бы не падало в продакшене. Автор просто восхищается тем, что Juju в продакшене не падал, а предыдущий проект вспоминается с «содроганием» :) Для «поделиться ощущениями» вполне пойдет, как аргумент в сравнении — вряд ли.
Пожалуйста. Вам спасибо за отзыв. Для меня это новый опыт. Читаю на английском достаточно много, но для себя — это одно, можно просто уловить суть и продолжать дальше. А для других переводить — это, оказывается, очень трудно и непросто.
Мне вот не понравился rust, не смог привыкнуть к его «свистульками и погремушкам», причем на уровне ощущений и эмоций, т.е. я не смогу объяснить — чем именно не понравился. Нет, так нет, я и не читаю статьи про rust.
Здесь же. И про сахар и соль отличные статьи.
Жаль. Совсем отвык от бумажных книг. А это какая-то юридическая особенность — у вас права на распространение именно печатной версии? Т.е. распространение электронной версии вам не разрешено или издательство считает этот вариант нерентабельным, к примеру?
Да, насчет
я погорячился. Можно, конечно, и так тестировать.
ИМХО, у Финча вариант изящнее, а вариант Герранда более трудоемкий.
Спасибо за ссылки, первую положил в закладки — вдруг пригодится…
Один из рецептов и приведен в статье. Можно ссылку, где почитать о других рецептах?
А сравнение с проектом на C# некорректное, да — там были другие люди, да и неизвестно, как он развивался. Вполне вероятно, что Juju на C# тоже бы не падало в продакшене. Автор просто восхищается тем, что Juju в продакшене не падал, а предыдущий проект вспоминается с «содроганием» :) Для «поделиться ощущениями» вполне пойдет, как аргумент в сравнении — вряд ли.