LINUX.ORG.RU

golang - не хочу возвращать err, хочу паниковать!

 , ,


0

3

Какая-то секта с этими err. Код распухает в несколько раз. Идея с defer выглядит довольно здравой - я в своё время делал такой defer для 1C и для Delphi. Но паника лучше, чем возврат err-ов. Таковой возврат ничего не упрощает. Когда выпадает исключение, сразу виден весь стек. Сгенерированный err не показывает места своего возникновения, т.е. с помощью брекпойнтов нужно много итераций, чтобы локализовать ошибку. А на fatalpanic есть чуть ли не встроенный брекпойнт, во всяком случае, у меня на fatalpanic отладка сама по себе останавливается.

Кроме того, разбор err после каждого вызова офигенно многословен, код распухает буквально в разы.

Я собираюсь попробовать в своих упражнениях максимально использовать панику. Труъ голангисты, разубедите!

★★★★★

Ответ на: комментарий от den73

И я прошу обратить внимание на вот это код:

func foo() (res *Z, err error) {
  res, err = bar()
  if err != nil {
    return }}
  doSomethingElse()
  return }
Ничем не отличается от простого пропуска исключения вверх без обработки. Если мы сделаем, что bar будет паниковать с тем же значением err, а не возвращать err, код запишется так:
func foo() (res *Z) {
  res = bar()
  doSomethingElse() 
  return }
Было 33 лексемы, осталось только 20. Т.е. код стал более чем в полтора раза компактнее, считая по числу лексем, гораздо более понятным и читаемым. Т.е. вопрос с точки зрения производительности труда совершенно непраздный. Конечно, обработка ошибки в обоих случаях осталась за скобками. Но ведь мы её в обоих случаях не обрабатываем, а всего лишь передаём вниз по стеку.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от WitcherGeralt

Ну понятно, что в команде придётся исполнять. С библиотеками тоже понятно. Но я уже умею получать err, печатать его, писать if-ы. Мне не нужно ничего здесь учить. А теперь я хочу узнать, как работать, чтобы было удобно. Я уже узнал благодаря этой теме про pkg/errors и прочая. Это вариант, он в целом решает проблему локализации ошибки, остаётся только многословность. Но я хочу больше вариантов. И не факт, что я буду работать в команде - это как пойдёт.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)

Не представляю как ты собираешься работать на дядю. На первом же ревью кода тебя завернут с этими паниками и таким самобытным форматированием. Ты словно из 90-х выпал, честное слово. Пойми, что изгаляться и тешить своих тараканов можно только в рамках собственного продукта. Иначе ты либо соответствуешь стандартом, либо идешь нафик. Там за тобой в очереди десяток молодых балбесов, готовых на любые надругательства ради места, подумай об этом. Стоит ли вот так донкихотствовать по мелочам?

anonymous ()
Ответ на: комментарий от WitcherGeralt

Убедительной аргументации просто ноль.

Меня бесит отсутствие возможности посмотреть какие исключения бросает функция. И отсутствие статических гарантий, как минимум в плюсах.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Забавно, а почему ты мне это не ответил? Не снизошёл, что ли? Если тебе известно, что функция возвращает error, это тебе даёт много знаний? Ты глядишь в исходник функции и видишь в ней эн вызовов других функций, которые возвращают err, и рассматриваемая тобой функция может их обрабатывать, а может возвращать. В чём разница с Java? Да ни в чём. Ты должен проанализировать всё дерево вызовов, чтобы узнать, какой error тебе может прийти. И в java так же. Только букв в golange при том же сервисе гораздо больше. Просто ты-то думаешь, что я дурачок, а ты вместо этого мог бы подумать о самом языке.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 3)
Ответ на: комментарий от RazrFalcon

Да. Не обрабатываешь на месте или бросаешь сам, будь добр это явно указать. Очень нужно, согласен.

Я думал их хотели выкинуть

Вот уж не знаю, не в контексте. Писал на джаве немного в 2012-2013, и эта фича мне приглянулась и запомнилась.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

В книге «чистый код» или «совершенный код» (их вроде несколько клонов) написано, что checked exceptions пользоваться не надо и что вроде в индустрии есть консенсус на эту тему. Впрочем, это лишь то, что написано в книге «чистый код», в полезности рекомендаций которой я сильно сомневаюсь.

den73 ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Меня тоже взбесил, когда я его впервые увидел, даже не стал вникать тогда. Сейчас жалею, ибо экосистема мне очень нравится. Синтаксис вторичен, для меня главное, что он хорошо читается и почти без лишних странностей.

WitcherGeralt ★★ ()
Ответ на: комментарий от den73

Потому что ты интереснее голанга, вот почему. Голанг это шлак для быстрой утилизации студентов гуглем, поэтому там все как в армии: упал-отжался, ать-два. И тут ты такой лезешь с рац.предложениями как лохматый советский инженер. Это просто анекдот с точки зрения нанимателя. Тебя нанимают не усовершенствовать голанг, ферштейн?

anonymous ()
Ответ на: комментарий от den73

Code complete? Я начинал читать, ибо отдельные высказывания Макконнелла мне нравятся, но дальше пары глав не пошел, только по диагонали пробежался, чтобы убедиться, что ничего не упускаю. Для неокрепших умов, полагаю, что прочтение будет полезным, но мне показалось, что там слишком много банальщины и вкусовщины.

в индустрии есть консенсус на эту тему

При этом в разных частях индустрии есть куча разных консенсусов, которые друг другу противоречат. Аргументы-то были?

WitcherGeralt ★★ ()
Ответ на: комментарий от anonymous

Раз я интереснее голанга, то это говорит в мою пользу. Если я буду писать как положено, меня стошнит уже на уровне упражнений, посему приходится изгаляться. Насчёт рацпредложений - я конечно же всё понимаю :) Я же не к работодателям пришёл с ними, а на ЛОР.

den73 ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

Аргументы-то были?

Да нет, не было. Было написано что-то типа «время споров прошло». Книжки под рукой нет. Возможно, что throws возникает более высокую связанность (нужно тянуть эти throws через весь стек, а это уже нарушает модульность, когда начинают взаимодействовать не соседние уровни, а далеко отстоящие друг от друга). Впрочем, если исключения переодевать при переходе на следующий уровень структуры приложения, то вроде как эта проблема должна решаться.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от jollheef

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

++

А если есть возможность отрепортить, то потом объясняй разработчику на пальцах, как воспроизвести. И в итоге UNCONFIRMED.

С трейсбеком видно где косяк. Если не видно, это не значит что косяка нет, это значит что программист — идиот (я не стану подбирать политкорректное слово в ущерб вложенному во фразу смыслу).

@RazrFalcon, я был лучшего мнения о тебе. Я понимаю, к чему ты изначально вёл, но ты всё равно не прав — идеального кода не существует, так как его пишут люди.

mord0d ()
Ответ на: комментарий от mord0d

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

anonymous ()
Ответ на: комментарий от anonymous

Да в Раст их собирались завести, см. https://stackoverflow.com/a/30824812/9469533 И вот это я не понял, что:

https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

В смысле, это похоже на catch, но я не знаю насчёт версий. Судя по url, это прям мейнстрим. В принципе это не столь важно для меня, скорее это важно для тех, кто считает, что исключения вообще не нужны. Они вроде не нужны, но пробиваются сквозь любую надгробную плиту, под которой их пытаются похоронить. В Обероне (blackboxcomponentbuilder) ситуация похожа на старый Rust, там мы не можем управлять локализацией исключения (оно отлавливается на границе команды UI), но сама по себе локализация есть и исключение тоже есть, а при этом оберонщики считают, что исключений нет, они не нужны, и готовы убить любого, кто начнёт выступать за исключения. Думается, создатели раста тоже где-то на оберон поглядывали. И религиозная преемственность тоже просматривается, прям как ислам с христианством от иудаизма. Правда, там нет и деструкторов, так что ситуация вроде как с одной стороны почище, а с другой - так и погрязнее.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от RazrFalcon

что на обработку ошибок нужно забить. А именно это и хочет ТС.

ХорошО, что ты это написал, теперь хотя бы понятно, в чём проблема. Нет, я не этого хотел. Я всего лишь хотел изображать то же самое с помощью паники, а не с помощью дикого таскания err-ов туда-сюда. Функционал и способ его оформления ортогональны. Я всецело за хорошую обработку ошибок.

den73 ★★★★★ ()
Ответ на: комментарий от den73

Надо завязывать на сегодня вообще-то. Не хочу конечно работать, но надо хоть что-то за день сделать. Вот результат на данный момент:

http://вики-ч115.программирование-по-русски.рф/Go/ОбработкаОшибок

В конце обсуждения перенесу в пост. Всем спасибо за участие, продолжим на днях.

den73 ★★★★★ ()
Ответ на: комментарий от den73

Он написал тоже самое что и я. Да, в Go/Rust есть механизм, который работает как исключения в C++/Java/etc. Но это не исключения. Они не случайно имеют другое название.

Читать до просветления: https://doc.rust-lang.org/1.30.0/book/second-edition/ch09-03-to-panic-or-not-...

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Я обеими руками за stack trace, но это не значит, что на обработку ошибок нужно забить.

Я неправильно тебя понял. Думал, ты предлагаешь скрывать ошибки по умолчанию (ах, ну да, ты же плюсовик).

mord0d ()