Эту проблему решили async/await в том же C#, которые решают проблему асинхронного программирования куда более изящно, нежели обычные такие fiber threads горутины с синтаксическим сахаром. Все исключения отлично пробрасываются туда, куда нужно и сохраняют правильный callstack. Даже если идет речь о чем-то вроде горутин, когда код отправляется на ThreadPool. Go естественно слишком прост, чтобы еще в нем модель async/await реализовывать.
Поэтому неудивительно, что там так прижился goto. Без него теже ресурсы освобождать в каждом if error != 0 это страх и ужас, который обязательно закончится утечкой ресурсов, которые забыл освободить в очередном обработчике ошибок.
Разница лишь в том, что в одном код ошибки, а в другом составной объект. Это все тот же механизм ошибка=значение. Ну и никто не мешает возвращать структуры в С в качестве ошибок и получить вообще копию Go подхода. Но так не принято, не более того. Поэтому сравнивать корректно, потому что механизмы за ними стоят идентичные. Можно себя долго обманывать и искать в Go новизну, но как уже множество раз говорилось авторами языка — в нем нет ничего нового.
Ну числа это тоже числа, однако в памяти это наборы байтов в определенном порядке. И знать little или big endian это надо, если хочется, чтобы вывелось правильно везде. Тут тоже самое. Текста в понятиях ПК не существует. Есть текст — суть, байты, которые в определенной кодировке дают текст на экране. А в другой уже не дают. Без кодировка нет текста, будь это UTF или даже просто ASCII. И я не видел ниодного рантайма, который бы не упоминал этих понятий. Просто напросто невозможно в полной мере манипулировать байтами, когда кодировка их содержимого неизвестна.
но подход Go тут является и зрелым и свежим одновременно
Зрелым, но никак не свежим. Описанное в статье это подход, который используется с бородатых времен. Смотрим на С и, внезапно, видим ровно тоже самое. Не мудрено, ибо Go использует чуть более расширенный их вариант.
Go просит программиста относиться к ошибкам также, как и к любому другому коду. Просит не рассматривать ошибки, как некоторую особую сущность, для которой нужен специальный подход/инструмент/паттерн, а трактовать код обработки ошибок также, как бы вы трактовали обычную логику вашей программы. Код обработки ошибки — это не особенная конструкция, это полноценная часть вашего кода, как и все остальные.
Только в большинстве случаев обработка ошибок это скорее вспомогательная часть на черный день, которая размывает основную логику в тех языках, которые используют подход ошибка=значение. Да, таких языков полно и Go тут опоздал на много много лет в свежести. Исключения позволяют отделить обработку того, что к логике мало относится — оно отделяет обработку исключительной ситуации, когда основная логика именно что не работает из-за ошибки. Да, значения проще, но ведут к более сложному коду, если конечно ошибки обрабатывать, а не игнорировать, как опять нас просят в Go.
Вернемся к Go. Он идеологически разделяет подход к работе с этими сущностями. Для предвиденных ошибок — это возвращаемое значение, это такой же результат работы процедуры и вы должны его обрабатывать (вы же не игнорируете результат, который возвращает процедура поиска первого вхождения подстроки в строке, даже если это "-1"?). Для непредвиденных исключительных ситуаций — это defer, panic и recover.
panic и recover в Go используются для эмуляции исключений. Когда код слишком глубоко опустился и его нужно размотать до определенного уровня. Почитайте про парсеры. И это таки видится более частным применением, нежели по прямому значению — завалить программу.
А defer, внезапно, это эмуляция finally/деструкторов С++ на стеке. Ни больше, ни меньше.
C++, C#, Java и др. идеологически используют единый подход для работы с ними
Нет, не используют. Вы, кажется, ни на одном не писали, раз так считаете. Есть исключения для исключительных ситуаций, которые не позволяют дальше продолжить нормально работу. Есть возвращающие значения функции как раз для подхода «ошибка это значение». Никто не путает и не мешает их, все на своих местах.
Вы читаете вообще. что вам пишут? Почему вы думаете, что у всех такой примитивный use case, когда можно просто грохнуться и ругнуться юзеру в консоль? Есть конкретные случаи, когда нет юзера, приложение автономно, ему некому и некуда бить тревогу. Оно должно всеми силами восстановить соединение. Простой пример, у меня были задачи, когда биндинг происходит на конкретный адаптер. Если этого адаптера нет, то в зависимости от настроек запускаются разные алгоритмы восстановления соединения, включая простую долбежку до победного, но это лишь один из вариантов. И в этом случае ошибка мне много чего скажет о том, как мне поступить. Потому что нет юзера, нет лога ошибок, есть требование — приложение должно само восстановить соединение и ни в коем случае не упасть из-за безобидной ошибки биндинга.
И я еще раз повторю, раз вы пропустили это. Listen это один из примеров. ВСЯ документация написана в ключе — ошибка возвращается, а какая — не скажу. Не счесть примеров, когда ошибка нужна и от нее зависит поведение программы. Я понял, что надо лезть в исходник и, за неимением альтернатив, смирился с этим. Но это признак плохой и, попросту, отсутствующей документации. Ее просто нет. Есть список функций на сайте. Чем-то напоминает doxygen документацию у многих инструментов — такая же бедная и бесполезная. Барахтайся как хочешь. Но одно дело какая-то third-party хрень, а другое дело runtime языка.
Я прекрасно помню, о чем была речь. Отсутствие проверок на тип произошедшей ошибки = отсутствие обработки ошибок. Выплюнуть nil и сообщение в консоль это игнорирование ошибки больше.
Как еще понимать вот это
я вижу метод с ошибкой и сразу пишу, что мне делать, что там за ошибка мне в принципе не очень то и важно.
Это какое-то универсальное правило или я такой уникальный, что в шарпах ошибки и исключения ловлю? Смотрю в документации, как функция может завалиться.
Зато я вот заметил другое — в Go людям плевать на ошибки. И мне здесь уже советовали плевать на ошибки. Все равно их все не обработать.
Если речь про cmd, то всегда можно использовать chcp 65001, если сменить в свойствах консоли шрифт. UTF8 батч файлы начинают говорить на разных языках.
Так а зачем было начинать общение, если вы не способны ответить на вопросы без перехода на личности и игры в попугая? Теперь будете хоть знать, что я привык аргументировать свою позицию, что показано в самом первом комментарии этой ветки. Было дано целых два аргумента, которые, впрочем, почему-то проигнорированы.
Я вас не просил отвечать мне. Я написал вопрос, дал аргументацию моей позиции. Вы зачем-то ворвались и вбросили «Выдерживают». Хотите помочь — аргументируйте позицию, если уж удосужились ответить.
Если вы настолько привыкли к эксепшенам, что готовы свято отстаивать их, переходить на личности и писать простыни гнева
Давайте не кидать стрелки. Вы это делали первым и неоднократно. Я позволили себе продолжить в том же ключе беседу, раз вам так привычнее. Не брезгую чуток в грязи покопаться.
простыни гнева
А вот и та самая предсказуемая реакция. Медиум, который читаем мое энергетическое поле по IP. Мне уже просто весело вести разговор. Пользы он не приносит.
Вы обманываете себя. Вы написали без доводов «Не выдерживают критики». Я, чтобы подчеркнуть несостоятельность такого аргумента, вам парировал — «Выдерживают».
Доводов было как минимум два в самом первом комментарии. Потрудитесь прочитать их и осознать, прежде чем врать.
У нас разные представления о культуре.
Мата нет — значит культурная форма. Представления они общие.
Так а почему бы не задать вопрос, почему все пишут подробную документацию, а авторы Go решили отделаться только назначением функции?
Почему бы не задать вопрос, почему был выбран конкретный дизайн ошибок, если он объективно проигрывает тем же исключениями? Почему при этом так легко проигнорировать ошибку?
Это какие-то запретные вопросы или все таки все в этом мире познается в сравнении? Когда для чего-то нет объективных причин, то встает резонный вопрос, а зачем тогда это сделано было? Вполне справедлив ответ — так захотелось. Рандомизированный select, с ответа Пайка, именно в ключе «так захотелось» сделан. Go похоже этим и живет, но меня пытаются убедить, что за всем скрывается глубокий смысл, который никто называть не хочет.
Параллельно с этим вы ещё на людей кидаетесь, пытаясь их оскорблять
Когда человек валяет дурака и ведет себя как малое дитя, особенно в технических обсуждениях (а его попытки пошутить точно так же тянут на попытку оскробления), я поступаю по-разному. Иногда просто игнорю человека, раз его не вразумить. Иногда подыгрываю как сейчас и намерено провоцирую в ответ, чтобы получить забавную реакцию, что сейчас успешно получается делать. Разговор давно ушел из разумного русла, человек с самого начала не хочет отвечать на конкретные вопросы, а лишь отнекивается и отшучивается. Вот и я решил пошутить.
Я задал уже кучу вопрос, но них все ответы в стиле «так надо, ваши проблемы». Я спросил про документацию ошибок, мне ответили «так надо, смотрите код». Я спросил про преимущества и причины дизайна ошибок, мне ответили «так надо, вы ничего не понимаете». Сколько еще мне надо наводящих вопросов задать, чтобы добиться конкретного ответа?
Ни авторы языка
Авторы языка именно должны, если они поставили задачу популяризировать свое детище. Они это делают, они показывают, рассказывают, почему зачем и как. И конкретно дизайн ошибок меня ничем не убедил, что он чем-то лучше. Я это конкретно написал, я написал конкретно почему. Что вы мне ответили? «Выдерживают». Вам нечего ответить или вы хотите просто оставить плохое мнение о себе, о вашей статьей и языке? Я уже писал и еще раз напишу — это просто слепая вера. По крайней мере все ваши комментарии написано в таком ключе.
не пишите, что это «херота» и «полное извращение и никак иначе».
Если вас задевает мое мнение о языке, то это ваши проблемы. В простонародье это называется «фанбой», «батхерт» и прочие замечательные термины, которые отлично показывают, когда человек не может абстрагироваться от объекта обсуждения, что принимает все на свой счет. Меня крайне удивляют некоторые решения и выражаю это в культурной, но яркой форме такими словами как «херота» и «извращение», что бы кратко и емко показать степено моего удивления
на что угодно но не на тип, либо сравнение с переменной вроде io.EOF, либо каст к интерфейсу вроде net.Error.
Скажите это официальным примерам со switch по типам ошибок. Это стандартный паттерн обработки ошибок в Go, если ошибка имеет конкретный тип, а не задана как переменная пакета.
да? то есть вы будете перечислять все ошибки почему не получилось забиндить порт? а если вдруг за будите какую?
Все таки лучше подготовиться к каким-то ошибкам, чем вообще ничего с ними не делать. Помоему все умные люди учат одному простому правилу — смотри на ошибку, которую тебе вернули, и обрабатывай ее. Как — дело конкретной программы. В Go мне просто не дают в документации возможности узнать, что я могу ожидать от функции. Это плохая документация. Я не должен лезть в код, чтобы узнать поведение функции в стандартном случае. Невозможность забиндить порт это стандартная ситуация, но она не описана. Это даже не критическая ситуация. Логичная реакция на нее — попробовать биндиться дальше.
И не надо придираться. Listen всего лишь пример, с которым я просто работал недавно. Если вам в жизни никогда не приходилось по-разному реагировать на ошибки из библиотек, то чего я могу поделать. Мне приходилось, хотя бы для того, чтобы замапить ошибки внутренние на ошибки уровня протокола, которые уже отправляются на другую сторону.
Собственно, непонятно, о чем вы спорите, если сами создатели языка приводят примеры обработки ошибок switch по типу, switch по значению, но категорически нерекомендуют что-то там парсить в строке ошибок. Наверное они подразумевают, что не все ошибки одинаково обрабатываются. Почему же прим этом такая документация плохая мне не понятно.
Так все таки вы ребенок или тот, кто писал прошлую статью? Задача авторов языка и вас, как его самопровозглашенного защитника, показать, по каким причин он в чем-то чем-то лучше. Я прошу — покажите. Что я видел выглядит неубедительно, а для некоторых вещей вообще нет объяснения четкого. Вы в ответ что-то про веру, про попугаев и т.д. Может вы уже перестанете дурака валять или просто закончим разговор, раз вам нечего ответить? Если вы верите, что у ошибок Go есть объективные преимущества, но не можете их назвать, то давайте сразу закончим, ибо это не техническая беседа. Живите сами со своими бесами в голове.
Я не вижу ее и в Go и ваши статьи каждый раз это только подтверждают. Так что паритет.
Ну и это, кажется вы прекратили со мной говорить во всех будущих темах. Что же случилось?
Пожалуйста, назовите их. В этот раз обойдусь даже без хероты и извращений.
Зрелым, но никак не свежим. Описанное в статье это подход, который используется с бородатых времен. Смотрим на С и, внезапно, видим ровно тоже самое. Не мудрено, ибо Go использует чуть более расширенный их вариант.
Только в большинстве случаев обработка ошибок это скорее вспомогательная часть на черный день, которая размывает основную логику в тех языках, которые используют подход ошибка=значение. Да, таких языков полно и Go тут опоздал на много много лет в свежести. Исключения позволяют отделить обработку того, что к логике мало относится — оно отделяет обработку исключительной ситуации, когда основная логика именно что не работает из-за ошибки. Да, значения проще, но ведут к более сложному коду, если конечно ошибки обрабатывать, а не игнорировать, как опять нас просят в Go.
panic и recover в Go используются для эмуляции исключений. Когда код слишком глубоко опустился и его нужно размотать до определенного уровня. Почитайте про парсеры. И это таки видится более частным применением, нежели по прямому значению — завалить программу.
А defer, внезапно, это эмуляция finally/деструкторов С++ на стеке. Ни больше, ни меньше.
Нет, не используют. Вы, кажется, ни на одном не писали, раз так считаете. Есть исключения для исключительных ситуаций, которые не позволяют дальше продолжить нормально работу. Есть возвращающие значения функции как раз для подхода «ошибка это значение». Никто не путает и не мешает их, все на своих местах.
И я еще раз повторю, раз вы пропустили это. Listen это один из примеров. ВСЯ документация написана в ключе — ошибка возвращается, а какая — не скажу. Не счесть примеров, когда ошибка нужна и от нее зависит поведение программы. Я понял, что надо лезть в исходник и, за неимением альтернатив, смирился с этим. Но это признак плохой и, попросту, отсутствующей документации. Ее просто нет. Есть список функций на сайте. Чем-то напоминает doxygen документацию у многих инструментов — такая же бедная и бесполезная. Барахтайся как хочешь. Но одно дело какая-то third-party хрень, а другое дело runtime языка.
Как еще понимать вот это
Зато я вот заметил другое — в Go людям плевать на ошибки. И мне здесь уже советовали плевать на ошибки. Все равно их все не обработать.
Я вас не просил отвечать мне. Я написал вопрос, дал аргументацию моей позиции. Вы зачем-то ворвались и вбросили «Выдерживают». Хотите помочь — аргументируйте позицию, если уж удосужились ответить.
Давайте не кидать стрелки. Вы это делали первым и неоднократно. Я позволили себе продолжить в том же ключе беседу, раз вам так привычнее. Не брезгую чуток в грязи покопаться.
А вот и та самая предсказуемая реакция. Медиум, который читаем мое энергетическое поле по IP. Мне уже просто весело вести разговор. Пользы он не приносит.
Доводов было как минимум два в самом первом комментарии. Потрудитесь прочитать их и осознать, прежде чем врать.
Мата нет — значит культурная форма. Представления они общие.
Почему бы не задать вопрос, почему был выбран конкретный дизайн ошибок, если он объективно проигрывает тем же исключениями? Почему при этом так легко проигнорировать ошибку?
Это какие-то запретные вопросы или все таки все в этом мире познается в сравнении? Когда для чего-то нет объективных причин, то встает резонный вопрос, а зачем тогда это сделано было? Вполне справедлив ответ — так захотелось. Рандомизированный select, с ответа Пайка, именно в ключе «так захотелось» сделан. Go похоже этим и живет, но меня пытаются убедить, что за всем скрывается глубокий смысл, который никто называть не хочет.
Когда человек валяет дурака и ведет себя как малое дитя, особенно в технических обсуждениях (а его попытки пошутить точно так же тянут на попытку оскробления), я поступаю по-разному. Иногда просто игнорю человека, раз его не вразумить. Иногда подыгрываю как сейчас и намерено провоцирую в ответ, чтобы получить забавную реакцию, что сейчас успешно получается делать. Разговор давно ушел из разумного русла, человек с самого начала не хочет отвечать на конкретные вопросы, а лишь отнекивается и отшучивается. Вот и я решил пошутить.
Авторы языка именно должны, если они поставили задачу популяризировать свое детище. Они это делают, они показывают, рассказывают, почему зачем и как. И конкретно дизайн ошибок меня ничем не убедил, что он чем-то лучше. Я это конкретно написал, я написал конкретно почему. Что вы мне ответили? «Выдерживают». Вам нечего ответить или вы хотите просто оставить плохое мнение о себе, о вашей статьей и языке? Я уже писал и еще раз напишу — это просто слепая вера. По крайней мере все ваши комментарии написано в таком ключе.
Если вас задевает мое мнение о языке, то это ваши проблемы. В простонародье это называется «фанбой», «батхерт» и прочие замечательные термины, которые отлично показывают, когда человек не может абстрагироваться от объекта обсуждения, что принимает все на свой счет. Меня крайне удивляют некоторые решения и выражаю это в культурной, но яркой форме такими словами как «херота» и «извращение», что бы кратко и емко показать степено моего удивления
Скажите это официальным примерам со switch по типам ошибок. Это стандартный паттерн обработки ошибок в Go, если ошибка имеет конкретный тип, а не задана как переменная пакета.
Все таки лучше подготовиться к каким-то ошибкам, чем вообще ничего с ними не делать. Помоему все умные люди учат одному простому правилу — смотри на ошибку, которую тебе вернули, и обрабатывай ее. Как — дело конкретной программы. В Go мне просто не дают в документации возможности узнать, что я могу ожидать от функции. Это плохая документация. Я не должен лезть в код, чтобы узнать поведение функции в стандартном случае. Невозможность забиндить порт это стандартная ситуация, но она не описана. Это даже не критическая ситуация. Логичная реакция на нее — попробовать биндиться дальше.
И не надо придираться. Listen всего лишь пример, с которым я просто работал недавно. Если вам в жизни никогда не приходилось по-разному реагировать на ошибки из библиотек, то чего я могу поделать. Мне приходилось, хотя бы для того, чтобы замапить ошибки внутренние на ошибки уровня протокола, которые уже отправляются на другую сторону.
Собственно, непонятно, о чем вы спорите, если сами создатели языка приводят примеры обработки ошибок switch по типу, switch по значению, но категорически нерекомендуют что-то там парсить в строке ошибок. Наверное они подразумевают, что не все ошибки одинаково обрабатываются. Почему же прим этом такая документация плохая мне не понятно.