А https://github.com/tucnak/telebot ?

Уже лучше. Про актуальность сейчас не знаю, но когда я им пользовался он тоже месяца так на два-три отстал. Тогда. Сейчас не знаю

Там коммит вчера последний, на счет актуальности не знаю.

Я всё равно психанул и пишу своё. Уже пару ботов перенёс, вроде без боли

Не проще было запуллреквестить нужную логику в готовые?

Не проще было запуллреквестить нужную логику в готовые?

В том-то и дело что меня не очень устраивает существующие архитектуры

go-telegram-bot-api, например, уже сложно фиксить из-за странных решений заложенных изначально

Через месяц повторим.

а на картинке что?

Код и ошибка.

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

Код и ошибка.

а текстом?

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

Неважно. Нужно.

а текстом?

Сукунду.

type Server struct { ID uint Title string NodeID uint }

Неважно. Нужно.

мне - важно. я решаю, помогать, или забить

func main() { srv := Server{3, "ProxmoxVE", 1} fmt.Println(srv.StructDisassemble()) }

func (S *Server) StructDisassemble() map[string]interface{} { disMap := map[string]interface{}{} instance := S elements := reflect.ValueOf(&instance).Elem() typeOfStruct := elements.Type() for i := 0; i < elements.NumField(); i++ { f := elements.Field(i) disMap[typeOfStruct.Field(i).Name] = f.Interface() } return disMap }

для такого простого кода (без нестандартных модулей) есть https://play.golang.org/

type Server struct { ID uint Title string NodeID uint }

Мне важно видеть имена полей ("ID", "Title", "NodeID"), и затем их значения, данные им в инстансе.

для такого простого кода (без нестандартных модулей) есть https://play.golang.org/

если так то хорошо.

Мне важно видеть имена полей ("ID", "Title", "NodeID"), и затем их значения, данные им в инстансе.

printf("%+v", pointer)

printf("%+v", pointer)

https://play.golang.org/p/9grvnZnhPJ

Поможете?

Поможете?

Оставь просто srv - https://play.golang.org/p/T1zox99TLf

Если Я правильно понял суть вопроса :)

Здорово.! Спасибо!

А что их тип еще видешь, тогда еще рефлект туда добавить, да?

А что их тип еще видешь, тогда еще рефлект туда добавить, да?

Если для каждого поля, то скорей всего да. Тут Я не помню :)) Но вообще, мне такое не часто требовалось )

Утра доброго! Господа, а есть ли способ быстро получить множество ошибок которые может вернуть какая-либо функция? Например есть api к телеграмму , есть функция которая ининциализирует бота package main import "gopkg.in/telegram-bot-api.v4" func main() { bot, err := tgbotapi.NewBotAPI("some very secret token") if err != nil { panic("Oh no!") } } В err может упасть дюжина разных ошибок (плохой токен, проблемы с сетью и т.д.). Можно ли как-то получить их список (имеется ввиду разные type NetError struct удолетворящие интерфейсу error) чтобы каждую по-своему обрабатывать, не излазив все исходники? Или даже примерного вспомогательного инструмента нет?

А что их тип еще видешь, тогда еще рефлект туда добавить, да?

Еще глянь https://github.com/davecgh/go-spew

Если для каждого поля, то скорей всего да. Тут Я не помню :)) Но вообще, мне такое не часто требовалось )

Спасибо. Обычно тоже не требуется, просто иногда я получаю ответ типа {0 0 0 0 0 0 0 1 2 0 0} и фиг пойми на каком ключе значение 1 стоит )))

Утра доброго! Господа, а есть ли способ быстро получить множество ошибок которые может вернуть какая-либо функция? Например есть api к телеграмму , есть функция которая ининциализирует бота package main import "gopkg.in/telegram-bot-api.v4" func main() { bot, err := tgbotapi.NewBotAPI("some very secret token") if err != nil { panic("Oh no!") } } В err может упасть дюжина разных ошибок (плохой токен, проблемы с сетью и т.д.). Можно ли как-то получить их список (имеется ввиду разные type NetError struct удолетворящие интерфейсу error) чтобы каждую по-своему обрабатывать, не излазив все исходники? Или даже примерного вспомогательного инструмента нет?

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

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

Ды, соглашусь, иногда и правда бесит, что на каждый err пачка if'ов

можно свитч по типу ?

можно, но стандарта на типизацию ошибок (как, например, в яве) в go нет

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

можно свитч по типу ?

не лучше :)

я думаю можно что-то подумать конечно с этим

кастомную либу сделать ?

можно

будет 15-ый стандарт

такие вещи должны в языке быть

Неужели автоматически собрать все типы которые могут вернуться в error так сложно? Чисто чтобы знать к чему нужно кастить ошибку?

впрочем - их нигде, кроме явы, и нет

в пыхе щаз мода на эксепшены ?

Неужели автоматически собрать все типы которые могут вернуться в error так сложно? Чисто чтобы знать к чему нужно кастить ошибку?

что возвращает fmt.Errorf()?

что возвращает fmt.Errorf()?

Строку в лог и завершение программы

os.Exit(1) вроде или типа того

Хотя может путаю с Fatal

Error!

садитесь, 2

она возращает error

errors.New он возвращает

Окей, спутал)

errors.New он возвращает

ну вообще то errorString если мы так про типы то

os.Exit(1) вроде или типа того

Мы Вам перезвоним :)

ну вообще то errorString если мы так про типы то

Нед

errors.New он возвращает

Ну да, когда все ошибки задаются через errors.New разобрать - черт ногу сломит. Но ведь часть разрабов пишут под каждую ошибку свою переменную или тип. Их-то собрать можно?

ну как нед?

а errors.New(), в свою очередь, возвращает указатель на неэкспортируемый errorString. Вокзал. В смысле - приехали...

ну как нед?

Он тебе возвращает указатель на объект error, у которого есть метод Error(), который и вернет тебе строку ;)

ERROR: S client not available

не бывает объекта error. error - это интерфейс, а не тип

Он тебе возвращает указатель на объект error, у которого есть метод Error(), который и вернет тебе строку ;)

мы вам тоже перезвоним

указатель на errorString, который реализует интерфейс error

не бывает объекта error. error - это интерфейс, а не тип

https://golang.org/src/errors/errors.go

ладно, errors ))

Будет. Она догоняет сам код

https://golang.org/src/errors/errors.go

и что же мы там видим?

return &errorString{text}

внезапно да

внезапно да

И ? Говорю ж, тебе вернется объект

ты говоришь что вернется объект типа error

хотя это не так

ты говоришь что вернется объект типа error

Тут был не прав, объект errorString да )

ты и сейчас не прав, тип то errorString называется ?

он просто реализует интерфейс error

ды :)

Но не строку ж в чистом виде

errorString это структура

если уже пошла такая пьянка

errorString это структура

А где Я это отрицал ?)

дайте стикер - "рукалицо", под рукой нет

?

коллеги

сворачивайтесь

тут не о чем так долго говорить

O_o ну мы же про гоу говорим

Ммм... Время слоупочных вопросов. А разве интерфейс сам по себе не тип? type I interface {} Все-таки type и все дела

сворачивайтесь

Рабочий день только начался, а переливание из пустого в порожнее любимое дело ))

Ммм... Время слоупочных вопросов. А разве интерфейс сам по себе не тип? type I interface {} Все-таки type и все дела

несколько типов могут реализовывать 1 интерфейс

несколько типов могут реализовывать 1 интерфейс

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