А вас в гугле забанили?

Например: https://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-slow и далее по ссылкам.

Или вот это: http://nibblestew.blogspot.com/2017/01/measuring-execution-performance-of-c.html

Или это для вас так же монастыри, уставы и ересь?

Не надо путать соглашения с инженерными решениями.

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

Подход к обработке ошибок - инженерное решение. Техническая тема. Здесь есть место для принятия взвешенного выбора. Для обсуждения плюсов/минусов, последствий для архитектуры системы, поведения системы, ее способностью к восстановлению и т.д. и т.п.

Это такой checked noexceptions, тоже полезно. Я под throws * имел ввиду «эта функция бросает checked exeptions такие, какие бросают функции вызываемые в ней».

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

Конечно шутка

Перенимать опыт нужно у «монстров» разработки.
https://habr.com/ru/post/429946/ Безумие и успех кода Oracle Database

В Go 2 будет тебе обработка ошибок

Есть мнение что это УГ. Теперь каждый вызов нужно заворачивать в check, а собственно обработка ошибки оторвана от места возникновения. Т.е. получаем такие кривые локальные ексепшны. Мне кажется лучше бы оставить все как есть, чем затыкать дыры в дизайне кривыми костылями. Интересно как они дженерики в синтаксис впихнут. Боюсь го2 совсем кособоким уродцем будет.

Это к обсуждению исключений отношения не имеет.

Но RazrFalcon-а этот вариант не устраивает.

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

Мы получили срез общества и видим, что общество мыслит религиозно, а не инженерно.

den73 познает мир

Нет. Но предполагаю, что в Java, checked exceptions сделали неудобными. В том же rust/swift они удобнее.

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

Если нужны пруфы: запустите любую прогу на расте с RUST_BACKTRACE=1 и она замедлится в разы, так как будут сохранятся стекфреймы(?).

И вот еще интересно, что теперь делать буратинам, у которых полна коробочка имен handle и check в коде? Они же не были зарезервированы, так? В общем меня терзают смутные сомнения насчет адекватности разработчиков Go.

https://www.youtube.com/watch?v=PpGcsrsyBjQ «Вы панике не поддавайтесь. Спасайтесь!»

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

Главное не пробовать Forth!

faq смотрел?

https://golang.org/doc/faq#exceptions

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

Ну кроме того, что можешь проматчить ошибку по типу.

Спасибо. Прямо сейчас некогда прочитать, но замедление в 10-20раз для исключений, и, что самое главное, если исключение не возникает, то код с исключениями быстрее, чем код с if error. Так что тут компромисс в обе стороны. Всё даже ещё более запущено, чем я думал сначала :) Кроме того, голанг (как потомок оберона) упирает на простоту, а не на быстроту. Поэтому высокая стоимость ошибок (которых в норме мало) вообще не должна кого-либо волновать.

Ну кроме того, что можешь проматчить ошибку по типу.

Я могу это сделать и в варианте с recover, причём код матчинга будет одинаковым.

faq смотрел?

Да там сплошная и прямая ЛОЖЬ написана. Почему я и говорю о секте. Секта - это там, где ложь. Поэтому это не то, что просто соглашения. Это когда вас пытаются обмануть и навязать решение на основе ложной информации. Например, о том, что panic/recover не требует дополнительных конструкций - это ложь. Здесь нужен defer, который в точности есть finally по поведению, просто код, выполняемый при раскрутке стека, расположен в другом месте - не в конце, а в начале. Делает ли это поток управления менее или более convoluted, чем finally? Вообще-то более естественно расположение finally как в Java и C# - управление идёт сверху вниз. defer, расположенный в точке инициализации, более удобный для чтения (захват и освобождение ресурса находятся рядом), но он более convoluted. Кроме того, без лямбд этот механизм вообще бы не работал. Т.е., если по честному, то механизм освобождения ресурсов при выходе устроен в голанге сложнее, чем в C++ или Java.

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

Forth я не пробовал, но книжку по нему прочитал ещё в студенчестве. Но лисп - это лучший Forth, чем сам Forth.

den73 познает мир

Я большую часть своей карьеры работал в одно лицо и клал с прибором на предрассудки. Теперь я стал старым и отстал от жизни, поэтому придётся согласовываться с социумом. Хотя я надеюсь вырваться в одиночное плавание, но это вряд ли сможет произойти сразу.

Есть мнение что это УГ. Теперь каждый вызов нужно заворачивать в check, а собственно обработка ошибки оторвана от места возникновения. Т.е. получаем такие кривые локальные ексепшны. Мне кажется лучше бы оставить все как есть, чем затыкать дыры в дизайне кривыми костылями. Интересно как они дженерики в синтаксис впихнут. Боюсь го2 совсем кособоким уродцем будет.

Соглашусь. Дженерики можно при необходимости реализовать через interface{}, а check будет дублировать частный случай паники. Это не по-обероновски. Хотя посмотрим, может быть они смогут изобрести нормальные дженерики.

Я могу это сделать и в варианте с recover, причём код матчинга будет одинаковым.

То есть все-таки

err error ничего не говорит о природе ошибки

немного неверно.

Некорректно сравнивать плюсы

Можно вынести этот факт за скобки и считать деструкторы defer-ами. Т.е. померять стоимость самого механизма. Хотя судя по ссылке eao197 на SO, не так просто померять.

https://stackoverflow.com/questions/13835817/are-exceptions-in-c-really-slow

Разница минимальна. В панике error (убогий интерфейс с одним лишь методом), а в recover - просто «любое значение», которое можно и в строку превратить с помощью «%v», и тип его узнать. Т.е. по сути, кроме количества букв, никакой разницы нет. Ну и аномальное значение panic(nil), конечно.

В том же rust/swift они удобнее.

Там нет checked exceptions. Они вообще только в java и есть.

работал в одно лицо и клал с прибором на предрассудки

Люди так не могут. В твоем случае ты опирался на свои личные предрассудки и «спорить» было не с кем=)

Там есть очень похожие механизмы. Как минимум в обоих чётко видно, что вызываем метод, который может вернуть ошибку.

Разница минимальна. В панике error (убогий интерфейс с одним лишь методом), а в recover - просто «любое значение», которое можно и в строку превратить с помощью «%v», и тип его узнать. Т.е. по сути, кроме количества букв, никакой разницы нет. Ну и аномальное значение panic(nil), конечно.

ЯННП, ну да ладно.

Там есть очень похожие механизмы. Как минимум в обоих чётко видно, что вызываем метод, который может вернуть ошибку.

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

Есть какая-то специфика именно голанга?

Не знаю насчет специфики, но языки и компиляторы разные. Вот тебе бенч:

main.go

package main

import (
	"errors"
)

func doErr() error {
	return errors.New("err")
}

func doPanic() {
	panic("panic")
}

func hasErr() string {
	if err := doErr(); err != nil {
		return "Here's error"
	}
	return ""
}

func hasPanic() (res string) {
	defer func() {
		if r := recover(); r != nil {
			res = "Here's panic"
		}
	}()
	doPanic()
	return
}

func main() {
}

main_test.go

package main

import "testing"

func Benchmark_hasErr(b *testing.B) {
	for i := 0; i < b.N; i++ {
		hasErr()
	}
}

func Benchmark_hasPanic(b *testing.B) {
	for i := 0; i < b.N; i++ {
		hasPanic()
	}
}

Benchmark_hasErr-4 2000000000 0.35 ns/op 0 B/op 0 allocs/op

Benchmark_hasPanic-4 10000000 133 ns/op 0 B/op 0 allocs/op

паника в 380 раз медленнее на моей машинке

Так я об этом же. В расте это ?, а в swift - try.

Это не религия, а этика, и образуется она неспроста.

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

Того же мнения. Но такое всегда случается когда хипстота набегает и начинает ныть. Уже не один язык так в уг скатился или хотя бы начал скатываться.

упирает на простоту, а не на быстроту

Да ладно? Смысла в Go тогда бы и вовсе не было. Проще Python ведь не бывает.

Го опенсорсный, может форкнуть его любой.

Форкни С#

Профайлер есть, как гугл говорит.

Давай ты ознакомишься с темой и дальше я поясню о чем я.

Еще

А еще

В рантайме под нагрузкой

И это прекрасно.

Это ты не видел как течет память в библиотеках.

Еще один недостаток Го - в нем нет библиотек.

фактически выполнили функцию компилятора.

Юниттесты ортогональны компилятору

Дефотный темплейтинг есть, хоть он примитивный. Куда ещё и зачем? Если кому-то действительно понадобится, то напишут.

Gccgo с вытекающими. Но сам не пробовал.

Чем тебя дефолтный не устраивает?

Да ладно? Смысла в Go тогда бы и вовсе не было.

Представь себе разработку оптимизирующего компилятора. У него 100500 флагов и 100500 оптимизаций. Нужно заставить работать все их сочетания. Оберон-вей - это сделать один, не оптимизирующий компилятор. За счёт простоты можно в сжатые сроки сделать его работающим правильно. Причём разница в трудоёмкости может комбинаторно зависеть от количества флагов и оптимизаций. Прекрасный пример оптимизирующего компилятора - это SBCL. Они постоянно в нём что-то меняют, и он постоянно сломан. LuaJit - второй пример.

С питоном сравнивать нельзя, т.к. это не компилятор вовсе.

В том то и дело, что я вообще удивился что написан хоть еще один.

Представь ситуацию, что тебе досталось легаси от «не такого как все» разраба

Ещё раз: err error никоим образом не защищает от помойки, потому что в статике невозможно узнать, какие ошибки могут прийти. Просто эта помойка ещё и разбавлена в эн раз шаблонным кодом, которого могло бы просто не быть.

Спасибо за замер. Дойдут руки - доделаю к нему happy path. Но тут ещё разница в том, что у тебя есть defer, которого нет в случае с err. В реальном коде defer будет в обоих вариантах, он будет закрывать, скажем, какой-нибудь файл. И обработка паники будет внутри этого defer. Т.е. пока это лишь один частный случай, полного анализа ситуации пока нет.

На самом деле, кроме скорости выполнения компьютера, который железный, есть ещё скорость диагностики ошибки, когда система падает в продакшене. Если в happy path паник нет, то резко облегчается локализация ошибки. Об этом я написал с самого начала темы.

Но во всяком случае, ясно, что скорость паники нужно учитывать при принятии решения.

Я ещё видел, но quicktemplate самый продвинутый, а дефолтный самый простой. Поискать, конечно, можно, но зачем? Факт в том, что стандартные батарейки покрывают большинство потребностей, а разрабов ещё не достаточно много, чтобы на каждый кейс было десяток альтернативных решений, да и дзен языка не особенно это подразумевает.

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

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

Пока до профайлера руки не дошли. Ты намекаешь, что там всё как-то ужасно? Я думаю, что если и так, то «скоро завезут».

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