а в целом, го доставил

Аналогично. Как платформа в целом — чем-то он притягивает :)

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

я вот таким образом реализую модель исключений и их отработки

var errorLLSNlist = map[int]string{
        100: "blabla blablabla",
}

type ErrorLLSN struct {
        code int
}

func (e *ErrorLLSN) Error() string {
        return errorLLSNlist[e.code]
}

func (e *ErrorLLSN) Code() int {
        return e.code
}

func oops(code int) {
        panic(&ErrorLLSN{code})
}

////// how to recover and get the error code/description

defer func() {
 		if r := recover(); r != nil {
 			rrr := r.(*ErrorLLSN)
 			fmt.Printf("Recovered error: [code %d] %s \n", rrr.Code(), r)
 		}
 	}()

собственно в коде дергаешь oops с кодом ошибки, а рекавер делаешь как тебе по логике нужно.

Ок, попробую ещё раз: с исключениями, если у нас какая-то функция в глубине стека вызов начинает что-то бросать нам не надо модифицировать ВСЕ промежуточные функции. С возвратом значения (в любой форме) - надо.

я не очень, но разве свифт не прячет это под капот?

речь про unchecked исключения в понимании большинства языков. В свифте их нет.

а что у нас свифт делает при обращении за границы массива?

Если в разных обучающих книгах и прочих «best practices» такое пишут, то что-то оно да значит.

в общем-то ничего оно не значит, кроме мнения автора книги. А кто у нас пишет обучающие книги? Правильно, тот, кто даже управлять не может.

Вряд ли. Так как у большинства функций сигнатуры на экран не влазили бы.

ну и собственно, что? Впрочем я не настаиваю, но блин, NumberFormatException в чем провинился-то? С остальными то хрен - если уж их выбросили - то программа обязана упасть.

Да почему его избегать-то, объясни? Проблемы решать проще, разрабатывать - сравнимо по сложности, а может и тоже проще. Люди - если так хочется, берешь чувака с опытом любого другого динамического языка, неделя-другая - и вот тебе нормального уровня программист на Erlang.

Единственное, в чем он сколько-то сложнее - деплоймент, тут не поспоришь. И то, ничего сверхсложного нет, все решаемо.

объясни

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

Люди - если так хочется, берешь чувака с опытом любого другого динамического языка, неделя-другая - и вот тебе нормального уровня программист на Erlang.

это известный факт, но предыдущих аргументов не отменяет

я не очень, но разве свифт не прячет это под капот?

Смотря что считать «прячет». Если у нас есть функции f1, f2, ... f100 и каждая последующая вызывает предыдущую, то если f1 начнёт выбрасывать исключения, то throws придётся дописать к каждой функции. Конкретные типы, действительно, не придётся.

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

а что у нас свифт делает при обращении за границы массива?

Сдохнет в рантайме.

в общем-то ничего оно не значит, кроме мнения автора книги.

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

ну и собственно, что?

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

шта?

Ну так-то он не сильно декларативнее того же Python-а. Никакой ленивости, никаких особенных заморочек. Единственное - стейт явный и акторы.

зачем нужен erlang, если не писать в функциональном стиле

Осторожнее, ты заплываешь жиром за буйки.

И вообще, по большому счету, на Erlang можно писать только в одном стиле, за небольшими различиями.

я в общем-то писал уже в то время, когда слово «продакшн» никто не знал, гг

По-моему, на такое отвечают «слив защитан», нет?

Ну так-то он не сильно декларативнее того же Python-а.

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

в принципе по барабану - если у тебя какое-то свое понимание терминов «императивный/декларативный» - можешь поменять мое «в глаза не видели императивщины» на «впитали функциональщину с молоком препода»

Никакой ленивости

ленивость тут вообще ни при чем

По-моему, на такое отвечают «слив защитан», нет?

может мне просто лень писать список, не? Тем более я часть названий даже не помню

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

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

Сдохнет в рантайме.

прикольно

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

толпа следует рекомендациям книжки? (что-то мне это напоминает) И что - ценность мнения определяется количеством последователей? Развитием java управляет сообщество методом прямого голосования? Нет же, не так всё - и даже наоборот.

и да, для любителей учиться по книжкам есть замечательные языки - php, c++, perl. Зачем они лезут в другие языки и трындят «вот тут у вас неправильно» ? (бгг)

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

ахахаха

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

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

А так спецификатор noexcept и в плюсах есть.

и да, для любителей учиться по книжкам

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

И да, «толпа» вполне следует популярным рекомендациям. Может не совсем явным образом, но тем не менее. Во всех нормальных более-менее крупных проектах есть свои правила и спускаются они не с неба, а вполне заимствуются из книг и опыта людей.

Ага, вот только какие именно исключения обрабатывать совершенно непонятно.

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

А документации может и не быть.

документации на что? Негде почитать, что такое FileNotFoundException или IOError ?

ну я даже не знаю :)

nb: в случае отсутствия документации при использоавнии unchecked exception - ты _понятия не имеешь_, что используемый тобой рантайм и библиотеки могут убить твое приложение в самый неподходящий момент.

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

обычно это разные книжки. Обучение языку и обучение программированию - это таки две большие разницы.

И да, «толпа» вполне следует популярным рекомендациям

а кто с этим спорит? Я всего лишь намекнул, что в рекомендациях может быть говно. Ну или неоднозначность. Вот ты прочитал где-то, что CE - это плохо. А аргументы выдумываешь на ходу, судя по «А документации может и не быть». Ну вот такое впечатление складывается.

я вот таким образом реализую модель исключений и их отработки

А вот и повылазили первые костылистроители. В Го каждый реализует свое видение искючений и генериков. А в ржавом обязательно найдутся (да чего говорить уже нашлись, достаточно поглядеть реализацию dom в servo) свои костылистроители в области эмуляции классического ООП.

Я бы добавил к мыслям го - пхп, еще одно дополнение: адская солянка из javascript и php. И вроде проходили это уродство, но нет опять на теже грабли. Судя по всему создатели были не в курсе об опыте мира веб-разработки.

А вот и повылазили первые костылистроители.

где тут костыль? я лишь сделал генерацию исключения по коду. штатный механизм panic/recover использует текстовое значение.

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

аноним шарит, впрочем как всегда

ты этим клоунам ничего не докажешь, они тебя закидают говнотоннами надуманных примеров где «исключение вылетает и я ловлю его через сто стекфреймов всего один раз!!111», то что при этом стейт приложения становится раком они как-то не учитывают. Точнее не понимают о чём говорят, уверен что любой из говноадептов исключений и мегабайта связного кода не написал за жизнь.

слышь, за базар ответь

приходится добавлять десятки, даже сотни if'ов

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

Пошли элитарные аргументы от неосиляторов исключений.

Они игнорят ошибки? Это многое объясняет.

О! Вспомнил ещё одну досаждающую мелочь. При многострочной записи цепных вызовов методов точку приходится ставить не в новой строке перед именем метода, подчёркивая продолжение цепочки методов, а в конце предыдущей строки. Это резко снижает эффективность визуального парсинга кода :-/

при этом стейт приложения становится раком они как-то не учитывают.

Он встаёт раком только если ты не умеешь исключения. Но тогда у тебя раком встанет стейт и в случае кодов возврата.

это ты то чепушила-онаним можешь в исключения?

нука показал мне тысячу строк своего strong exception-safe кода, быстро нах!

Зачем ему это делать? Ты не умеешь исключения и признался в этом.

Что ты используешь для обработки ошибок? Судя по примеру хрома, ты пишешь на крестах. Видимо, коды возврата. При этом не очень понятно, как ты обходишься без if'ов. Можешь показать свой код.

Если это хром/хромиум/яндекс-браузер, то к меня для тебя плохие новости.

онаним не может в русский язык(

Ты не умеешь исключения и признался в этом.

где ты это увидел петух? я умею _не пользоваться_ исключениями, в отличии от тебя

как ты обходишься без if'ов

ты вменяемый вообще? не можешь в контекст?

для тебя плохие новости

я тебе ещё раз говорю, петушина ты эксепшнальный, покажи мне тыщу строк своего кода с strong exception guarantee, можешь даже не своего, иди на гитхаб и принеси мне его. Если не можешь - то залепи своё дуло либо вон из профессии!

Как тебя разрывает-то :D

Успокойся, напиши хотя бы один пост в адекватном состоянии, тогда продолжим.

почему?

Ну потому что сигнатуры нет. В итоге приходится полагаться на документацию (если есть) и на сообщения компилятора.

документации на что? Негде почитать, что такое FileNotFoundException или IOError ?

Мы вообще-то про свифт говорили. Так что документации на то, что функция «бросает».

при использоавнии unchecked exception - ты _понятия не имеешь_

Не имею (с оговорками), и? Ты опять зациклился. Смотри ещё раз: «возврат ошибки» явный и поэтому его (если сделан нормально) сложнее проигнорировать. Исключения хороши как раз возможностью обработать «где-то потом». checked exceptions, по сути, относятся к первому варианту. И тут ты мне говоришь, то что я и так знаю.

Вот ты прочитал где-то, что CE - это плохо. А аргументы выдумываешь на ходу, судя по «А документации может и не быть»

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

свои костылистроители в области эмуляции классического ООП.

Очень лениво искать... можешь ссылку на конкретный файл кинуть? А то любопытно посмотреть будет.

Ну и «наследование» в каком-то виде хотят добавить. Этого недостаточно?

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

Ну потому что сигнатуры нет. В итоге приходится полагаться на документацию (если есть) и на сообщения компилятора.

а куда она делась? Idea берёт сигнатуру из астрала, чтобы подсветить мне метод, в котором я не обрабатываю исключение? Или ты опять про свифт? Но мы же исключения обсуждали .... алкоголик.жпг

Мы вообще-то про свифт говорили.

мы вообще-то говорили про checked/uncheked, а про свифт я больше спрашивал. Насколько я понял - в свифте исключениями обозвали ошибки, а возможности обработать именно исключения - там нет. Ну окей

Не имею (с оговорками), и?

без оговорок. Не имеешь и всё.

Смотри ещё раз: «возврат ошибки» явный и поэтому его (если сделан нормально) сложнее проигнорировать.

ты не допускаешь мысль, что бывают ошибки, игнорирование которых приводит к быдлокоду просто в силу природной лени homo sapiens ?

Исключения хороши как раз возможностью обработать «где-то потом»

ну да, тяпляпать проще :)

Наличие кучи статей показывают, что не один я так думаю

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

Ты чего такой буйный? Вываленный код, в написании которого ты принимал участие, не является аргументом, это очевидно.

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

nb: в случае отсутствия документации при использоавнии unchecked exception - ты _понятия не имеешь_, что используемый тобой рантайм и библиотеки могут убить твое приложение в самый неподходящий момент.

В таком крайнем случаеты можешь отлавливать все и заворачивать в свой тип исключений.

У тебя были случаи, когда checked exception были полезны? Мне вот нравится из 11ых крестов noexcept. Вот это полезно.

Какой-то пустой срач. Исключения — говно. Коды возврата — говно. Да даже рестарты говно. Остаётся полагаться только на монады.

В таком крайнем случае ты можешь отлавливать все и заворачивать в свой тип исключений.

мне _все_ вызовы чужих функций заворачивать в try ?

да ты гребаный гений!

У тебя были случаи, когда checked exception были полезны?

у меня были случаи, когда unchecked exception оборачивались громадным геморроем. Когда геморроем оборачивались checked - ни одного.

Мне вот нравится из 11ых крестов noexcept. Вот это полезно.

ну молодец

монады - тоже говно

Почему?

А с низкой квалификацией программистов нужно бороться

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

Почему?

не могу придумать остроумный ответ :(

не могу придумать остроумный ответ :(

Да ладно, когда тебя это останавливало.

мне _все_ вызовы чужих функций заворачивать в try ?

На границе модулей, как говорится.

На границе модулей, как говорится.

на какой границе? Ты о чем вообще? В приложении используется N классов из библиотеки Y - ты предлагаешь _все_ конструкторы и все вызовы методов в try {} пихать? Или весь main в try завернуть?

без оговорок. Не имеешь и всё.

А как же документация, на которую ты сам ссылался?

ты не допускаешь мысль, что бывают ошибки, игнорирование которых приводит к быдлокоду просто в силу природной лени homo sapiens ?

С чего такой вывод? Я ж наоборот говорю, что явность и сложность игнорирования является плюсом. Вот только не всего оно надо - у меня не так уж редко бывали ситуации когда удобнее обработать потом.

ну да, тяпляпать проще :)

Зачем передёргиваешь? Я говорю об обработке, а не игнорировании. А последнее можно делать независимо от того как у нас ошибки выражаются.

потому что от заказчика приходят внезапные копипасты стектрейсов.

Неправильно использовать можно любой инструмент. Хрень можно сделать и с явными ошибками или checked исключениями.

А то, что стектрейсы до заказчика регулярно доходят говорит лишь о том, что продукт никто не тестировали нормально.

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

Остаётся полагаться только на монады.

Дык, всякие там Maybe и Either - это ведь, по сути, «коды возврата».

У полноценных монад есть bind, а там и до do-сахара недалеко.

А как же документация, на которую ты сам ссылался?

надо разжевать, походу.

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

случай 2. анчекед - даже при наличии документации нет никаких гарантий, что кодер её посмотрел и обработал факап, или написал «вот это вот надо обработать где-нибудь наверху»

всё просто же. Два варианта всего.

С чего такой вывод?

оооооооопыт

Я говорю об обработке, а не игнорировании.

какая обработка? Ты не знаешь, что тебе вылезет и поэтому наверху ловишь вообще всё на всякий случай. Грубо говоря - в main() у тебя всё завернуто в try и catch() вообще на всё, что ты не обработал там где надо. Что ты там будешь обрабатывать? Перезапускать основной цикл программы? Писать «ой, неизвестная ошибка, прастити» ? Это и есть игнорирование

А то, что стектрейсы до заказчика регулярно доходят говорит лишь о том, что продукт никто не тестировали нормально.

сказочник, ты не в курсе, что тестирование и боевое применение - это разные вещи? Тебе никакое тестирование не даст гарантий, что не случится факап. А с твоим подходом тяпляпальшика - в один прекрасный день может выясниться, что твоё ПО неделю ничего не делало. Ну потому что у тебя catch() в main стоит на всё.

Хрень можно сделать и с явными ошибками или checked исключениями.

разумеется. Я веду речь о том, что с анчекед ошибку допустить _проще_, потому что ЯП менее строг к погроммисту.

Ну и странный у тебя архитектор получается, раз не может требования устанавливать

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

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

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

А если ты не знаешь, как его обработать и не можешь передать выше(поскольку поломаешь клиентский код)?

случай 2. анчекед - даже при наличии документации нет никаких гарантий, что кодер её посмотрел и обработал факап, или написал «вот это вот надо обработать где-нибудь наверху»

Ну и что? Это нормальная ситуация. Не знаешь, что делать - скажи об этом клиенту своего класса. Только безопасно работая со своим состоянием(я хоть и не крестовик, но мне очень нравится принятая у них система «гарантий безопасности исключений»).

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

Часть ошибок ты знаешь, часть нет. То, что можешь обработать - обрабатываешь сразу. То, что не можешь - прокидываешь дальше. В чем трудности?

всё просто же. Два варианта всего.

По этому пункту у нас разногласий нет. Что и зачем было разжевывать непонятно. Кажется, ты снова споришь сам с собой.

оооооооопыт

По моему, ты потерял контекст: сначала говоришь, что я не понимаю о том, что игнорирование ошибок приводит к быдлокоду. Я интересуюсь откуда вывод о непонимании и, в очередной раз, соглашаюсь, что явность (и как следствие меньшая вероятность случайного игнорирования) является плюсом. В ответ ты говоришь про опыт.

Ты не знаешь, что тебе вылезет и поэтому наверху ловишь вообще всё на всякий случай.

Придумывать-то не надо. Ловлю я то, что ожидаю, а ожидаю то о чём прочитал в документации, ну или что вылезло на тестах и при ручном тестировании.

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

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

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

Опять с зеркалом говоришь?

а что тебе ревью даст - совершенно непонятно.

Очень даже понятно. Если мы договорились не кидать unchecked исключений вообще, то можно бить по рукам тех, кто это делает. Ну а если это происходит в сторонней либе - так, опять же, к исключениям оно относится весьма опосредовано.

В чем трудности?

В том, что человек спорит сам с собой и придумывает аргументы аля «у тебя catch(...) на верхнем уровне!».

А если ты не знаешь, как его обработать и не можешь передать выше

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

Ну и что? Это нормальная ситуация. Не знаешь, что делать - скажи об этом клиенту своего класса.

«ув. заказчик, наше приложение может внезапно ничего не делать, потому что гениальный анонимус посоветовал в main вставить catch на всё вообще.
да, даже сообщений об ошибках мы не выводим. Прастити нас если чо»

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

не ты ли мне говорил, что в хороших книжках ты вычитал, что CE - это плохо? Я вот собственно из этого делаю вывод о непонимании. Потому что одновременно утверждать, что checked exceptions - плохо/неудобно, и что «явность ... является плюсом» - как-то не способствует пониманию

Очень даже понятно. Если мы договорились не кидать unchecked исключений вообще, то можно бить по рукам тех, кто это делает.

по-твоему, плюс к своему коду - надо проводить ревью кода сторонних библиотек и рантайма? лолъ

такое ощущение, что с приветмиропейсателями общаюсь, чесслово.

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