>>3308189 →

> Пацаны, поясните за обработку ошибок. Там выше кто-то уже спрашивал, но мне кажется тема ерроров осталась нераскрыта.

>

>Допустим у меня http обработчик сидит в самом верху, дергает метод из пакета (будем считать для простоты, что у меня 1 application layer = 1 пакет) А, тот дергает метод из пакета В, тот дергает метод из пакета С. Каждый из пакетов имеет свою структуру для ошибок: ErrorA, ErrorB, ErrorC, которые я могу набивать всяким полезным контекстом, чтоб потом его высрать в тело респонса жсоном. Собственно два вопроса:

>

>1. Как лучше сделать: чтобы пакет B при получении ErrorC оборачивал ее дополнительно своей ErrorB? Или ErrorB -- это чисто ошибки, относящиеся к самому пакету В? В первом случае вроде получается чето более-менее похожее на нормальный стектрейс, если у всех ошибок будет допустим какое-то поле Cause error, но тогда наверху у меня всегда будут только ошибки ErrorA, и если мне нужно разное поделать в зависимости от того, что же там за real cause была -- будет неудобно. Во втором случае стектрейса никакого нахуй нет, как такие ошибки например логгировать с пользой -- непонятно, но код проверки ошибок в обработчике становится хотя бы поприятнее.

>

>2. В обоих этих случаях выходит так, что обработчик должен быть в курсе обо всех ошибках, которые могут произойти во всем ебаном приложении, то есть он должен знать и про ErrorA, и про ErrorB, и про ErrorC. Чето я слабо себе представляю, как такой подход будет скейлиться, если аппка становится хоть сколько-то большой (ну там на пару десятков эндпоинтов хотя бы). Какие есть альтернативные варианты? Я сам чето ничего не надумал более умного.

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

Если же я буду все ошибки сервиса отдавать в виде одной структуры type ServiceError struct, то рано или поздно может случиться так, что в контроллере понадобится разная обработка сервисных ошибок и я пососу хуй. Если же буду заводить отдельную структуру на каждую ошибку бизнес-логики, то контроллер вырастет в размерах просто до огромных размеров и его станет невозможно поддерживать.

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

Чото не кликает у меня в голове голанг. Не понимаю, как писать, чтобы в итоге не получалось какое-то месиво. Из того, что прям вызывает максимальное отторжение:

- Утиные интерфейсы. По моему какая-то лютая нечитаемая хрень. Вместо того, чтобы просто глянуть сигнатуру класса и узнать, что именно он реализует (и, соответственно, куда его можно скормить), нужно каким-то блять магическим образом угадать, основываясь на прикрепленных к структуре функциях, какой же сука интерфейс она реализует (сам интерфейс ясен хуй валяется вообще в другом пакете, и это считается очень идиоматично и круто). Хуй поймешь в чем профит такого дизайн-решения.

- Отсутствие нормальных неймспейсов. В традиционных ООП языках все можно красиво рассовать по пакетикам и классикам, каждый из которых автоматически родит новый неймспейс для всего, что внутри. В го по факту пакеты это единственный способ родить неймспейс, ничего мельче нету. Сами пакеты внутри представляют собой какие-то солянки всякой всячины, наваленной в кучу по принципу "ну вроде из той же оперы". Ублюдочное решение с capitalized названиями функций/переменных для определения их визибилити.

- Работа со строками и массивами с каких-то хуев идет не через прицепленные к ним методы, а через strings и slices. Я хуй знает, может я чего-то не понял, но мне чето кажется, что говно в духе strlen, strncpy и прочее просто нахуй не должно существовать в новом языке, когда очевидно, что s.length и s.substring() выигрывают в читабельности и удобстве на порядки.

- Абсолютно надуманная нахуй не нужная еботня с pointer vs value.

- Работа с ошибками. По факту предлагается на выбор два сорта говна, которые можно еще и смешивать между собой - sentinel values и создание кучи абсолютно одинаковых структур под разные типы ошибок. Первый подход еще можно использовать без рвотных позывов благодаря errors.Is(), но при необходимости в таком случае достать дополнительный контекст ошибки начинается трахомудия. Второй подход более гибкий, если это слово сюда вообще применимо, но проверка типа ошибки через errors.As() это ебаный кал собаки, раздувающий сервисы/хэндлеры до космических размеров на ровном месте.

- Крайняя невыразительность языка. Даже тернарника нет, ебаный стыд. Вечная еботня с шэдоуингом ерроров, возвращаемых вторым значением в кортеже. Идиотская надуманная разница между = и :=.

Пока что понравилось по большому счету только принудительное форматирование кода из коробки к единому стилю, и каноничные табы вместо пробелов для отступов.

>>12011

>- Утиные интерфейсы.

Это отдельный пиздец, особенно если структура гуляет через методы где тип пустой интерфейс отдельная тема, тогда узнаешь о том что не имплементирует в рантайме. Какой вообще долбоеб додумался до такой хуеты, чтобы он каждый раз узнавал что его туалет не имплементриовал туалетную бумагу каждый раз когда он посрет

>- Отсутствие нормальных неймспейсов.

Тоже пиздец, я бы сюда еще цикличные импорты добавил

>- Работа со строками и массивами с каких-то хуев идет не через прицепленные к ним методы, а через strings и slices. Я хуй знает, может я чего-то не понял, но мне чето кажется, что говно в духе strlen, strncpy и прочее просто нахуй не должно существовать в новом языке, когда очевидно, что s.length и s.substring() выигрывают в читабельности и удобстве на порядки.

Ты еще более интимно со слайсами не познакомился, при присвоении другой переменной там не всегда понятно ты со старым работаешь или создался новый. Это такой кривой дизайн

>- Абсолютно надуманная нахуй не нужная еботня с pointer vs value.

Это кстати наоборот полезная вещь когда знаешь что передал конкретно ссылку и конкретно значение, это позволяет избежать дополнительного выделения памяти, особенно когда гоняешь одну и ту же структуру по калопроводам бизнес логики

>- Работа с ошибками.

Это говно ебучее, с той же философией сделали в расте и оно удобнее когда вместо бойлерплейта наверх пробрасываешь при помощи ? но там проблема что разные типы друг в друга не впихуются и приходится брать anyhow или колхозить свой тип ошибок и писать From для каждого типа, которых собираешься впихнуть, тоже говнясто, но уже лучше чем в go.
Этот подход с ошибками с одной стороны хорошо ты начинаешь обрабатывать ошибки которые мог бы не учесть при исключениях и уже добавляешь нужное поведение. С другой стороны для обычного бекенда чтобы гонять json туда-сюда это крайне избыточно, такое хорошо наверное где требуется высокая паранойя и ответственность чтобы не одна ошибка не проскочила. В остальных случаях проще наверху ловить в try/catch ролбекать транзакцию и посылать нахуй клиента. В той нише куда залетел го я думал лучше было бы второе.

>- Крайняя невыразительность языка. Даже тернарника нет, ебаный стыд. Вечная еботня с шэдоуингом ерроров, возвращаемых вторым значением в кортеже. Идиотская надуманная разница между = и :=

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